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