[Openid-specs-ab] audit in OIDC
Richer, Justin P.
jricher at mitre.org
Mon Aug 11 15:41:22 UTC 2014
The thing is, the data doesn't necessarily have to be carried inside the token, and that's why I was suggesting using the "jti" as the key for the whole thing. My argument is that it doesn't actually matter whether or not it changes for subsequent ID tokens (or access tokens, if you're formatting them), so long as you can trace it back at the AS or some other auditing component in the system. This is where the table that Zhanna mentions comes in to play, you'd have something like this:
jti | user | auth_time | client
abc1 | alice | 20140811:1119 | clientapp
xyz2 | alice | 20140811:1119 | clientapp
asdf | bob | 20140811:1119 | otherapp
Basically, downstream you just log the JTI as a reference to the authentication event, and you keep the back references from the JTI to the event in a table someplace where you can look them up. You can do the same thing with access tokens by indexing a JTI value or some other token reference (I know of things that store token hashes, for instance).
I think these approaches are fairly similar in implementation: You could easily create a unique "session_id" in that table as well, if you wanted to do it with something explicit other than the combination of user/client/auth_time. However, the crux of my argument is that most of the downstream items don't need to have access to (or knowledge of) this session identifier since the actual auditing will be done somewhere else. The important thing is that the whatever's recording the events to be audited needs to have some reference point that the auditing system can key off of.
I think it's another open question of whether or not this actually needs to be interoperable, since an auditing system seems (to me) to be fairly implementation specific. I can see the logic for wanting a session_id for session management, and so leveraging that for other items would be helpful if it were available.
On Aug 7, 2014, at 4:56 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> A session_id might be a random or at-least unique string set by the IdP.
> From the RP's point of view if it wants audit it can use nonce and send it in a signed request to prevent tampering.
> As an example the RP would start by constructing it's identifier for the session and sending it to the IdP where the IdP can store it and must send it back unchanged in the id_token, along with the Idp's session identifier (assuming we make that extension).
> Nothing stopes the IdP from including a claim about the user session in the refresh or access tokens.
> John B.
> On Aug 7, 2014, at 4:48 PM, Zhanna Tsitkov <tsitkova at MIT.EDU> wrote:
>> Hello John,
>> Yes, I need something in lines with session_id…. (Basically, this is where I was coming from when I suggested to have a random alphanumeric string for audit identifier)
>> On the other hand, I would like to better understand the value of having the identifier that can be deducted/calculated from the “known” parameters, that is created based in some rules/formulas.
>> On Aug 7, 2014, at 3:35 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>> Connect dosen't specify any format for access tokens, those are implementation specific.
>>> There has been discussion around the need for a session_id to allow backchannel messages to reference particular sessions.
>>> At the moment the closes thing to that is nonce which is set by the Client and returned in the id_token. It is however opaque to the AS so probably not suitable.
>>> Is a ssession_id more of what you are looking for? The jti is intended to stop token replay and will be changed if the id_token is refreshed.
>>> John B.
>>> On Aug 5, 2014, at 5:20 PM, Zhanna Tsitkov <tsitkova at MIT.EDU> wrote:
>>>> I am looking at introducing audit feature to OIDC. More specifically, I would like to have an Audit_id - an identifier that is used for audit purposes and can be traced to the particular participant of the OIDC session. Audit_id should stay unchanged and be available to all end-to-end participants of the exchange. Once generated, the audit_id can be recorded as part of audit logs at any stage of the exchange and, ideally, be available to downstream RS’s (or somehow deduced/back-traced ).
>>>> Audit_id can be either an alpha-numeric string (either randomly generated or something in lines with "audit_id=sub+auth_time+jti") or some json structure. Audit_id can be generated and signed by OP upon successful end-user authorization and then carried as an optional parameter in the further processing. Alternatively, as Justin Richer has suggested, one can use access and ID token jti’s as "audit id" and have a table (at the AS) of relationships indexed by token identifier.
>>>> The data of interest for audit includes permissions, policies, scopes, claims, authZ, authN related information. For example, it can be used by government for audit purposes (banks, government agencies), or for audit log dynamic processing for the fast violation response systems, revocations etc. The relevant Common Criteria document can be found here: http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf
>>>> Your input and comments are appreciated.
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab