On Wed, May 17, 2017 at 10:26 AM, Prabath Siriwardena <[email protected]> wrote:
> Also - related to JWT/SAML grant types - do we have an option to JIT > provision the user...? > This is not available in the current implementation. > The expectation is - when you enable JIT provisioning under the trusted > IdP - and pick the userstore to provision the users - then the user should > be JIT provisioned... > If we need to support OIDC with JWT/SAML grant types we need to have this this feature. even though OIDC spec does not talk about supporting OIDC with custom grant types this can be treated as token exchange mechanism And +1 for supporting this. -Ishara > > Thanks & regards, > -Prabath > > > On Tue, May 16, 2017 at 8:58 PM, Pushpalanka Jayawardhana <[email protected]> > wrote: > >> >> >> On Tue, May 16, 2017 at 11:15 PM, Ishara Karunarathna <[email protected]> >> wrote: >> >>> >>> >>> On Tue, May 16, 2017 at 10:25 PM, Prabath Siriwardena <[email protected]> >>> 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 < >>>> [email protected]> 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: [email protected], 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/p >> ushpalanka/ | Twitter: @pushpalanka >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 <(650)%20625-7950> > > http://facilelogin.com > -- Ishara Karunarathna Associate Technical Lead WSO2 Inc. - lean . enterprise . middleware | wso2.com email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
