[mitreid-connect] support for acr in id_token

[Justin Richer]

No, there’s no session sharing between the authorization and token endpoints. I was talking in terms of tracking through the authorization step, which would eventually need to get distilled into the OAuth2Request object that gets saved and picked up in the latter part of the transaction.

 — Justin

> On Mar 11, 2015, at 1:59 AM, Naveen Jamal <nj at tyfone.com> wrote:
> 
> thanks justin.
> 
> the cleaner option seems like the way to go. that was the way i was trying to approach the problem.
> 
> as far as the first option, just to be clear, since the /token request originates from the relying party and the not the end user's browser, the two can't share any HTTP session info..  so you're suggesting using spring's security context object instead ? i'm very new to java and spring, so please bear with me :)
> 
> ;n
> 
> 
> 
> On Tue, Mar 10, 2015 at 7:48 PM, Justin Richer <jricher at mit.edu <mailto:jricher at mit.edu>> wrote:
> Naveen,
> 
> Your best bet is probably going to be to put something into the user's session to indicate how they came in, then reach into that object when you're building the ID Token in your own version of the OIDCTokenService. You can access Spring Security's current security context object statically, so this shouldn't be hard to pull off.
> 
> Alternatively (and probably more cleanly), you can save it into the Authentication object itself, probably in the extensions Map that's in there. We use that map for things like prompt conditions, authentication time, and other components. Take a look at how the AuthenticationTimeStamper class works as an example of this, which sets the auth_age parameter in the ID Token.
> 
>  -- Justin
> 
> 
> On 3/10/2015 8:02 AM, Naveen Jamal wrote:
>> hi all,
>> 
>>   i'm trying to extend the openid connect server to support returning an acr value in the id_token based on how the user authenticated (username/password, OTP, soft token, hard token, ...) .
>> 
>>   i've been able to display a custom login form that accepts the necessary extra text fields (along with username and password) based on the acr_values passed to the authorize endpoint, and can also validate the extra user input to decide which acr was achieved.
>> 
>>   i'm having trouble figuring out how to get the acr (as inferred by the login submission) returned via token endpoint. i see that i'll have to add acr to the idClaims object in DefaultOIDCTokenService.java to get it to be returned as part of the id_token, but can't figure out how to make the acr value inferred at login form submission to be accessible at the DefaultOIDCTokenService. Seems like it needs to be part of the stored in the authentication longblob field in the authorization_code table?
>> 
>>   any suggestion on how i should go about this?
>> 
>>   thanks in advance,
>> 
>> -naveen
>> 
>> 
>> 
>> _______________________________________________
>> mitreid-connect mailing list
>> mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/mitreid-connect <http://mailman.mit.edu/mailman/listinfo/mitreid-connect>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150311/eac5e55f/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150311/eac5e55f/attachment.bin