On Sun, Mar 12, 2017 at 11:36 AM, Johann Nallathamby <[email protected]> wrote:
> > > On Sun, Mar 12, 2017 at 8:15 AM, Gayan Gunawardana <[email protected]> wrote: > >> >> >> On Sun, Mar 12, 2017 at 7:09 AM, Johann Nallathamby <[email protected]> >> wrote: >> >>> >>> >>> On Sun, Mar 12, 2017 at 7:04 AM, Thanuja Jayasinghe <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Sat, Mar 11, 2017 at 11:33 AM, Johann Nallathamby <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sat, Mar 11, 2017 at 8:58 AM, Thanuja Jayasinghe <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Johann, >>>>>> >>>>>> We use same "claim management" in SP configuration as well. So these >>>>>> attributes will be available for them also. When it comes to "userid", >>>>>> two >>>>>> SPs which use same claim configuration can have two different claims. >>>>>> >>>>> >>>>> No. Two SPs can request two different claims as the Subject. But the >>>>> unique user identifier claim must be specific to the dialect. E.g. SCIM >>>>> 2.0 >>>>> defines "userName" as the human-friendly unique identifier for the user. >>>>> SCIM 2.0 in fact defines the "id" claim also which is a non-human-friendly >>>>> unique identifier for a user. Although we don't need to support multiple >>>>> unique identifiers we at least need to support one so that it will be the >>>>> default subject if user doesn't select any other claim. >>>>> >>>> >>>> So, we also provide the ovridding capability at the SP configuration >>>> level? >>>> >>> >>> Yes. Like we had in 5.3.0 we have "Subject Claim" configuration. >>> >> There will be claim mapping from foreign dialect to wso2 dialect. We >> select subject claim from wso2 dialect by looking at mapping. If two >> inbound protocols (same SP) point to two different wso2 claims how can we >> configure it ? >> > > Two different inbound protocols having two different subject claims is not > a logical scenario. Even if the inbound protocols use two different claim > dialect they should point to the same wso2 claim logically. If that kind of > requirement is coming up then that is going beyond our concept of service > provider dialect. These kind of use cases come up only 1 out of 100 cases, > due to some problematic requirement in the entire solution. Not a problem > in the OOTB features. So in that situation I would suggest to register them > as 2 SPs, instead of going to change our concept of having a subject claim > per protocol. This is how we had in IS 5.3.0 also, and AFAIK didn't face > major issues. If we go to have subject claim per protocol, then all the SP > specific configurations, like role claim, requested claim, etc. will have > to go under each protocol level, which I don't agree. > > Wdyt? > +1 In that case having 2 SPs should be fine. > > >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> So, to avoid the confusion shall we rename it to something like >>>>>> "feduserid"? >>>>>> >>>>> >>>>> If we go by my above explanation this is not required. >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> On Mon, Mar 6, 2017 at 3:09 AM, Johann Nallathamby <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Any foreign dialect that we define using claim management, must have >>>>>>> two special attributes indicating the "userid" claim and the "role" >>>>>>> claim. >>>>>>> >>>>>>> "userid" claim is required for use cases like authentication and >>>>>>> provisioning. "role" claim is needed for role mapping and access >>>>>>> control. >>>>>>> >>>>>>> In C4 we had this at the IDP configuration level. In C5, since we >>>>>>> have extracted all the claim configuration from IDP to "claim >>>>>>> management", >>>>>>> and just refer to the dialect alone in IDP configuration, we need to >>>>>>> identify these two special attributes also in the claim dialect >>>>>>> management >>>>>>> level. This configuration will be fixed for any real IDP. >>>>>>> >>>>>>> What are your ideas? >>>>>>> >>>>>>> -- >>>>>>> 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>* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Thanuja Lakmal* >>>>>> Senior Software Engineer >>>>>> WSO2 Inc. http://wso2.com/ >>>>>> *lean.enterprise.middleware* >>>>>> Mobile: +94715979891 +94758009992 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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>* >>>>> >>>> >>>> >>>> >>>> -- >>>> *Thanuja Lakmal* >>>> Senior Software Engineer >>>> WSO2 Inc. http://wso2.com/ >>>> *lean.enterprise.middleware* >>>> Mobile: +94715979891 +94758009992 >>>> >>> >>> >>> >>> -- >>> 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 >>> >>> >> >> >> -- >> Gayan Gunawardana >> Software Engineer; WSO2 Inc.; http://wso2.com/ >> Email: [email protected] >> Mobile: +94 (71) 8020933 >> > > > > -- > 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>* > -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: [email protected] Mobile: +94 (71) 8020933
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
