In the current implementation of SAML and JWT bearer grants we treat the user coming with the grants as federated users always.
This is not always the case since there are scenarios where the SAML/JWT token will be issued by the same IS instance that will accept them later as bearer grants and issue tokens. Therefore ideally we need to treat these users as local users. Since we are planning to do an improvement to provision federated users I think this improvement would be necessary. Otherwise we would be blindly provisioning all the users irrespective of whether they are local or federated users. There was a discussion[1] related this for SAML bearer grant earlier as well. I think we could consider that improvement along with this fix. WDYT? [1] [Dev] Validate user against given user store and save correct user domain in saml2-bearer grant type On Wednesday, May 17, 2017, Prabath Siriwardena <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > Can we give the option to provision the user...? This requires no UI > changes - can read the option from the IdP config... > > Thanks & regards, > -Prabath > > On Tue, May 16, 2017 at 10:26 PM, Ishara Karunarathna <[email protected]> > wrote: > >> >> >> On Wed, May 17, 2017 at 10:37 AM, Prabath Siriwardena <[email protected]> >> wrote: >> >>> >>> >>> On Tue, May 16, 2017 at 10:04 PM, Ishara Karunarathna <[email protected]> >>> wrote: >>> >>>> >>>> >>>> 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. >>>> >>> >>> In fact this not related directly related ODIC - just the JWT grant type >>> (JWT grant type for OAuth 2.0).. >>> >>> if this is not supported then - in API M - how do we generate the JWT >>> for the backend - when users come from a federate JWT..? >>> >> In this case we only provide sub element, APIM should do the same >> >>> >>> Thanks & regards, >>> -Prabath >>> >>> >>> >>>> >>>> -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/pushpalanka/ | 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 <071%20799%206791> >>>> >>>> >>>> >>> >>> >>> -- >>> 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 <071%20799%206791> >> >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://facilelogin.com > -- Farasath Ahamed Software Engineer, WSO2 Inc.; http://wso2.com Mobile: +94777603866 Blog: blog.farazath.com Twitter: @farazath619 <https://twitter.com/farazath619> <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
