[mitreid-connect] support for acr in id_token

[Naveen Jamal]

just to close this out, i ended up putting my code (that sets the acr value
in authorizationRequest.extensions) in TofuUserApprovalHandler.
thanks again justin,

;n


On Wed, Mar 11, 2015 at 5:56 PM, Justin Richer <jricher at mit.edu> wrote:

> 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> 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 listmitreid-connect at mit.eduhttp://mailman.mit.edu/mailman/listinfo/mitreid-connect
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150316/bf02a1d4/attachment.htm