On Sun, Jul 24, 2016 at 12:35 PM, Hasanthi Purnima Dissanayake <
[email protected]> wrote:
> Hi Johann,
>
>> Any reasons for not giving this in the UI? Since we are doing this for IS
>> 5.3.0 we can do API additions; so it shouldn't be a problem to add new APIs
>> to support this in Resident IDP UI AFAIU.
>
>
> Yes. To support multi-tenants this should be a UI level configuration. But
> as we had to implement nearly 20 test cases for Alpha with in two weeks we
> decided to go with file config change which supports only for super tenant
> for the certification.
>
Ok understood.
>
>
> Is this kind of a configuration really required? The spec tells us what
>> claims should be included for which scope. Then why do we need this
>> configuration? Is it to restrict certain claims if the IDP wishes to? The
>> mail doesn't state what you are trying to achieve here.
>
>
> We discussed to provide such a configuration to support custom scopes and
> custom claims. Though the spec does not say anything about custom scopes or
> claims in the discussion, Darshana raised the concern that our customers
> had some requirements about custom scopes and claims. So we decided to go
> with such a file based configuration.
>
So I assume one can change the default claims sent for any of the
predefined scopes as well. E.g. if someone removed email claim for email
scope and keep only email_verified claim then we send only that. Right? If
so it looks fine.
>
>
>> @Hasanthi, did you check "5.5. Requesting Claims using the "claims"
>> Request Parameter" section? It is very much relevant to all of this claims
>> related stuff we are trying to do. Better check on that and come to a
>> conclusion of the design.
>>
>
> Yes, I checked that part and it has been already implemented as a separate
> test case. So the customer can send essential claims with the authorization
> request with 'claims' request parameter and obtain that claims from
> UserInfoEndpoint or ID token.
>
>>
>>>>> 3. If there are no requested claims, according to the above
>>>>> configurations the matching claims will be issued from the user info
>>>>> endpoint according to the scope.
>>>>> eg1: If the user requested openid email scope the claims will be
>>>>> sub,email,email_preferred (When the claims of the openid scope has been
>>>>> configured as *sub* in identity.xml).
>>>>> eg2. If the user requested openid email scope the claims will be {all
>>>>> the mapped attributes},email,email_preferred (When the claims of the
>>>>> openid
>>>>> scope has been configured as *all* in identity.xml).
>>>>>
>>>>
>> This is correct, but again why do we need "all" configuration?
>>
>
> I needed to keep the default behavior which we had previously with the
> 'openid' scope. That's why introduced the 'all' configuration.
>
AFAIK the old behaviour is to add sub claim and all the requested claims to
the IDToken and UserInfo token. If client sends "openid" as the scope, we
add the sub claim and any requested claims. If he sends additional scopes
we add those claims too. This way old and new clients both will work. I
don't think we need "all".
I think the difference is in your point no. 2; you are ignoring scopes that
are sent in the request and adding only the requested claims. Have you
designed it this way as a way to control the claims that are requested by
the service provider? If so I can see a valid reason there.
I am trying to avoid new configurations as much as possible to make it
simpler for the users who are configuring it. But if you can reason it out
as required then we can have it.
>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: [email protected]
> M :0718407133| http://wso2.com <http://wso2.com/>
>
> On Sun, Jul 24, 2016 at 3:02 PM, Johann Nallathamby <[email protected]>
> wrote:
>
>> Any reasons for not giving this in the UI? Since we are doing this for IS
>> 5.3.0 we can do API additions; so it shouldn't be a problem to add new APIs
>> to support this in Resident IDP UI AFAIU.
>>
>> On Mon, Jul 18, 2016 at 7:15 AM, Johann Nallathamby <[email protected]>
>> wrote:
>>
>>> Why are we not giving a UI based configuration? This should be a
>>> multi-tenanted configuration right?
>>>
>>> On Thu, Jul 14, 2016 at 3:17 PM, Hasanthi Purnima Dissanayake <
>>> [email protected]> wrote:
>>>
>>>> Hi Isura,
>>>>
>>>> Yes when we mark 'all' in the xml for scope 'openid' it behaves as the
>>>> previous way. We need to rethink whether it is the correct behavior as it
>>>> is sending all the claims without considering other scopes. So other scopes
>>>> become useless. How ever yes, we are using 'openid' scope to behave it as
>>>> the previous way.
>>>>
>>>> Thanks,
>>>>
>>>> Hasanthi Dissanayake
>>>>
>>>> Software Engineer | WSO2
>>>>
>>>> E: [email protected]
>>>> M :0718407133| http://wso2.com <http://wso2.com/>
>>>>
>>>> On Thu, Jul 14, 2016 at 2:28 PM, Isura Karunaratne <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Hasanthi,
>>>>>
>>>>> What is the default behaviour of claims of the openid scope? I think
>>>>> it should be "all".
>>>>>
>>>>> Thank
>>>>> Isura.
>>>>>
>>>>> On Thu, Jul 14, 2016 at 11:08 AM, Hasanthi Purnima Dissanayake <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> I'm implementing the $subject and the plan is as below.
>>>>>>
>>>>>> 1. The scopes and supported claims will be defined in identity.xml as
>>>>>> below.
>>>>>> <OpenIDConnect>
>>>>>> <scopes>
>>>>>> <scope id="openid">
>>>>>> <claims>sub</claims>
>>>>>> </scope>
>>>>>> <scope id="email">
>>>>>> <claims>email,email_preferred</claims>
>>>>>> </scope>
>>>>>> <scope id ="profile">
>>>>>> <claims>name, family_name, given_name, middle_name, nickname,
>>>>>> preferred_username, profile, picture, website, gender, birthdate,
>>>>>> zoneinfo,
>>>>>> locale, updated_at</claims>
>>>>>> </scope>
>>>>>> <scope id="phone">
>>>>>> <claims>phone_number, phone_number_verified</claims>
>>>>>> </scope>
>>>>>> <scope id="address">
>>>>>> <claims>address,street</claims>
>>>>>> </scope>
>>>>>> </scopes>
>>>>>> </OpenIDConnect>
>>>>>>
>>>>>
>> Is this kind of a configuration really required? The spec tells us what
>> claims should be included for which scope. Then why do we need this
>> configuration? Is it to restrict certain claims if the IDP wishes to? The
>> mail doesn't state what you are trying to achieve here.
>>
>> @Hasanthi, did you check "5.5. Requesting Claims using the "claims"
>> Request Parameter" section? It is very much relevant to all of this claims
>> related stuff we are trying to do. Better check on that and come to a
>> conclusion of the design.
>>
>> As much as possible try to avoid file based configurations because they
>> can't be multi-tenanted. If possible try to avoid configurations at all
>> which will be even simpler.
>>
>>
>>>>>>
>>>>>> 2. If there are any requested claims, the requested claims will be
>>>>>> issued ignoring the scope when the claims of the openid scope has been
>>>>>> configured as *all* in identity.xml. The requested claims will be
>>>>>> issued considering the scopes when the claims of the openid scope has
>>>>>> been
>>>>>> configured as *sub* in identity.xml
>>>>>>
>>>>>
>> The "all" config doesn't look very good.
>>
>>
>>>
>>>>>> 3. If there are no requested claims, according to the above
>>>>>> configurations the matching claims will be issued from the user info
>>>>>> endpoint according to the scope.
>>>>>> eg1: If the user requested openid email scope the claims will be
>>>>>> sub,email,email_preferred (When the claims of the openid scope has been
>>>>>> configured as *sub* in identity.xml).
>>>>>> eg2. If the user requested openid email scope the claims will be {all
>>>>>> the mapped attributes},email,email_preferred (When the claims of the
>>>>>> openid
>>>>>> scope has been configured as *all* in identity.xml).
>>>>>>
>>>>>
>> This is correct, but again why do we need "all" configuration?
>>
>> Ideally high level behaviour should be we would return any claims
>> indicates by the scopes that relying party is requesting, as long as the
>> IDP policies allow it (I assume this is why you have suggested a
>> configuration; there is no other reason for a configuration; this should
>> come to the Resident IDP UI IMO), and on top of that we will also add the
>> requested claims always.
>>
>>
>>
>>>
>>>>>> Any suggestions will be highly appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Hasanthi Dissanayake
>>>>>>
>>>>>> Software Engineer | WSO2
>>>>>>
>>>>>> E: [email protected]
>>>>>> M :0718407133| http://wso2.com <http://wso2.com/>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Isura Dilhara Karunaratne*
>>>>> Senior Software Engineer | WSO2
>>>>> Email: [email protected]
>>>>> Mob : +94 772 254 810
>>>>> Blog : http://isurad.blogspot.com/
>>>>>
>>>>> <https://wso2.com/signature>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>>
>>> *Johann Dilantha Nallathamby*
>>> Technical Lead & Product Lead of WSO2 Identity Server
>>> Governance Technologies Team
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+94777776950*
>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Technical Lead & Product Lead of WSO2 Identity Server
>> Governance Technologies Team
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+94777776950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
--
Thanks & Regards,
*Johann Dilantha Nallathamby*
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware
Mobile - *+94777776950*
Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
