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..? 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/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 <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
