Hi Johann,
>> >> 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. > Yes this is exactly what we have implemented. 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". Yes this what we had previously. But according to the new implementation when we are issuing claims we are considering the scope too. E.g. Think we have provided "openid" as the scope and request email as a requested claim. As we don't have email scope in the request we are not issuing the claim "email" here. We are issuing only the "sub" claim. But if the user needs to customize he can add email claim under the "openid" scope in the configuration. If so the server will return "email" claim too. 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. No. According to the new implementation (if we don't define "all" as the claim for "openid") we are considering the scopes if there are some requested claims and we are issuing those requested claims, only if they come under a scope which consists in the request. But if we have "all" as the claim of "openid" scope, then it ignores the scope in the request and adding only the requested claims. 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. Understood. The main purpose of theses configurations are to provide a control over claims and scopes and to preserve the previous behaviour with the current behaviour. Thanks, Hasanthi Dissanayake Software Engineer | WSO2 E: [email protected] M :0718407133| http://wso2.com <http://wso2.com/> On Mon, Jul 25, 2016 at 3:53 AM, Johann Nallathamby <[email protected]> wrote: > > > 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
