*Hi,*

*As per the offline discussion with IAM team, following is the agreed
design.*



*Darshana/Maduranga/Farasath/IAM Team - Please do correct me if I have
misunderstood regarding this.*

*Thanks.*

Regards,
Megala

On Thu, May 24, 2018 at 9:41 AM, Megala Uthayakumar <[email protected]> wrote:

> Hi,
>
> As per the meeting held offline, it was decide to only send the custom
> claims when the scope is given as "openid". Sending custom claims that are
> not defined in dialect can be supported by adding new claims to openid
> dialect and by appending the relevant scopes to "/oidc" resource in config
> registry.
>
> Thanks.
>
> Regards,
> Megala
>
> On Wed, May 23, 2018 at 2:41 PM, Bhathiya Jayasekara <[email protected]>
> wrote:
>
>> Thanks, I just understood the scenario.
>>
>> Thanks,
>> Bhathiya
>>
>> On Wed, May 23, 2018 at 2:36 PM, Megala Uthayakumar <[email protected]>
>> wrote:
>>
>>> Hi Bhathiya,
>>>
>>> On Wed, May 23, 2018 at 1:05 PM, Bhathiya Jayasekara <[email protected]>
>>> wrote:
>>>
>>>> Hi Megala,
>>>>
>>>> On Wed, May 23, 2018 at 10:11 AM, Megala Uthayakumar <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I am working on $subject for IS 5.5.0.
>>>>>
>>>>> When handling custom claims, we do have two options.
>>>>>
>>>>>    1. Handling custom claims as we have handled it in the
>>>>>    SAML2BearerGrantHandler.
>>>>>       - Current SAML2BearerGrantHandler converts the claims coming
>>>>>       from IDP to local claims and then filter out oidc claims only, 
>>>>> given that
>>>>>       scope is given as openid.
>>>>>       2. Handle relevant custom claims as it is when scope is not
>>>>>    openid and if the scope is openid filter out the openid scopes as we 
>>>>> do for
>>>>>    SAML2BearerGrantHandler
>>>>>       - If the scope is not openid, add all the custom claims with
>>>>>       the access token.
>>>>>       - If the scope is openid, follow the same approach followed by
>>>>>       SAML2BearerGrantHandler.
>>>>>
>>>>> I think option 2 is better way to handle this, becuase,
>>>>>
>>>>> JWT do not restrict the collection of custom claims, hence if we go
>>>>> with option 1, customer is expected to select one of the open id claims to
>>>>> get his claims back in original incoming JWT.
>>>>>
>>>>
>>>> Could you please explain this line further?
>>>>
>>> In our wso2 IS server, we have predefined list of oidc claims[1], but in
>>> JWT we can have custom claims that are not defined in our list.
>>>
>>> For example,
>>> A thrid party identity provider may send a claim with the name
>>> "testClaim" with its JWT token and the service provider may expect the same
>>> claim with the same name, but this cannot be done in our case, as we only
>>> pass the predefined set of oidc claims to service provider.
>>>
>>>
>>>> And in the subject you meant generating access token (but not JWT
>>>> token) right?
>>>>
>>> Self contained access token, which is a JWT token. [2]
>>>
>>>
>>>>
>>>> Thanks,
>>>> Bhathiya
>>>>
>>>
>>> [1] https://docs.wso2.com/display/IS550/Configuring+Claims+f
>>> or+an+Identity+Provider#ConfiguringClaimsforanIdentityProvid
>>> er-MappingconfiguredclaimstoanOpenIDConnectclaim
>>> [2] https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens
>>> <https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens>
>>>
>>>
>>> --
>>> Megala Uthayakumar
>>>
>>> Senior Software Engineer
>>> Mobile : 0779967122
>>>
>>
>>
>>
>> --
>> *Bhathiya Jayasekara*
>> *Associate Technical Lead,*
>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>
>> *Phone: +94715478185*
>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>> <http://www.linkedin.com/in/bhathiyaj>*
>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
>> *Blog: http://movingaheadblog.blogspot.com
>> <http://movingaheadblog.blogspot.com/>*
>>
>
>
>
> --
> Megala Uthayakumar
>
> Senior Software Engineer
> Mobile : 0779967122
>



-- 
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to