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?


>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> 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>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to