On Tue, May 16, 2017 at 11:15 PM, Ishara Karunarathna <isha...@wso2.com>
wrote:
>
>
> On Tue, May 16, 2017 at 10:25 PM, Prabath Siriwardena <prab...@wso2.com>
> wrote:
>
>> How do you figure out users from different idps?
>>
> In this way we can only identify whether use is federated or local user.
>
> But we can use a convention to keep IDP name as well if we need to go
> without schema changes
> Ex FEDERATED:IDP1
>
Is this to address any future issues or cater for features?
I can see a conceptual fault saving same domain name for different IDPs,
along with the unique key constraint we have. This can lead to treat two
identities as same, since we will only know they are federated.
CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TENANT_ID,
*USER_DOMAIN*,USER_TYPE,TOKEN_SCOPE_HASH,
TOKEN_STATE,TOKEN_STATE_ID)
What will be the places we will make use of the knowledge of authenticated
IDP?
>
> -Ishara
>
>>
>> Thanks & regards,
>> -Prabath
>>
>> On Tue, May 16, 2017 at 7:23 AM, Pushpalanka Jayawardhana <la...@wso2.com
>> > wrote:
>>
>>> Hi All,
>>>
>>> We have below 3 issues that are caused mainly because we don't have a
>>> clear way to distinguish local and federated users in oauth related tables
>>> (authorization code and access token storage).
>>> There are few more issues related to sending subject claim in proper
>>> format in IDtoken, that needs to identify the user as federated or local.
>>>
>>> In order to address these issues we need to check whether user is from
>>> a federated IDP. To fix this without having DB schema changes, IsharaK came
>>> up with this idea to use 'UserStoreDomain' column,
>>> to store the value 'FEDERATED' as user store domain for tokens and
>>> authorization codes issued to federated users. The relevant authenticators
>>> and grant handlers are responsible to set 'isFederatedUser' flag to true,
>>> whenever they are creating and passing an authenticated user to
>>> messageContext. OAuth storage will read and store it as the userStoreDomain
>>> value with 'FEDERATED'. This domain is never expected to be sent out from
>>> server as a user attribute or property or as part of username.
>>>
>>> In order to avoid any conflicts, we will avoid users from creating user
>>> store domains with the name 'FEDERATED'.
>>> If you see any pitfalls with this approach, please raise. We are
>>> proceeding with implementation as above.
>>>
>>> [1] - https://wso2.org/jira/browse/IDENTITY-5939
>>> [2] - https://wso2.org/jira/browse/IDENTITY-4880
>>> [3] - https://wso2.org/jira/browse/IDENTITY-4512
>>>
>>> Thanks,
>>> --
>>> Pushpalanka.
>>> --
>>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
>>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/
>>> Mobile: +94779716248
>>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p
>>> ushpalanka/ | Twitter: @pushpalanka
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>
>> Mobile : +1 650 625 7950 <%28650%29%20625-7950>
>>
>> http://facilelogin.com
>>
>
>
>
> --
> Ishara Karunarathna
> Associate Technical Lead
> WSO2 Inc. - lean . enterprise . middleware | wso2.com
>
> email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile:
> +94717996791 <071%20799%206791>
>
>
>
--
Pushpalanka.
--
Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/
Mobile: +94779716248
Blog: pushpalankajaya.blogspot.com/ | LinkedIn:
lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
