Yes - we know the issuer of the token - so we can control what to provision....
Thanks & regards, -Prabath On Wed, May 17, 2017 at 9:11 AM, Farasath Ahamed <[email protected]> wrote: > 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]> 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 <+1%20650-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 > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://facilelogin.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
