On 15 December 2016 at 01:11, Farasath Ahamed <[email protected]> wrote:
> > > On Thu, Dec 15, 2016 at 12:33 PM, Rajith Vitharana <[email protected]> > wrote: > >> >> >> On 15 December 2016 at 00:59, Farasath Ahamed <[email protected]> wrote: >> >>> On Wed, Dec 14, 2016 at 8:59 PM, Rajith Vitharana <[email protected]> >>> wrote: >>> >>>> Hi IS team, >>>> >>>> In [1] when getting the user, it doesn't validate whether the user is >>>> in a user store or not. (This happens in saml2-bearer grant type and IS >>>> trust the saml assertion. It's totally valid not doing this) >>>> >>>> but can we give the user the freedom to choose whether to validate the >>>> user in saml assertion against a given user store or not? >>>> >>> >>> >>> If we let the user to choose to validate the user against a user store >>> or not, the assertions coming from trusted IDP for a federated users will >>> fail if he chooses to validate the user in userstore? >>> >> Yes, we can make this configurable and use current behavior as default, >> If user needs this behavior, he will need to provide the userstore details >> which he needs the user to be validated against. >> > > > Hmm that makes sense. But once he enables this option he will no longer be > able to accept SAML bearer tokens from Federated IDPs (say like Google) > right? > we can make this per IDP right? without making this a global config. so that he can disable this for google right? > > > What i mean is, when user enables that option, he would only be able to >>> use assertions issued by IS or a federated IDP that shares a userstore with >>> IS. >>> >>> Instead wouldn't it be better if we only check the user in the user >>> store if the assertion was issued by us (by us I mean IS that is validating >>> the SAML assertion). We can check this using the SAML IdpEntityId. For >>> those assertions not issued by us, we could treat them as coming from a >>> federated IDP for a federated user. >>> >>> In which case it will actually have a valid user and correct user domain >>>> in the token table, in which case he can generate jwt tokens with required >>>> claims for that user. Is this a valid scenario? if so can we support this? >>>> >>>> Note that since we are taking the user domain from the >>>> username(subject) in [1], we can send username(saml assertion subject) with >>>> correct domain(ex: Secondary/username1) in which case it will save the >>>> correct domain in token table. Hence jwt flow works fine. But I feel like >>>> it's kind of a hack for this. >>>> >>>> I have created a public jira for this in [2] >>>> >>>> [1] - https://github.com/wso2/carbon-identity/blob/master/co >>>> mponents/oauth/org.wso2.carbon.identity.oauth/src/main/java/ >>>> org/wso2/carbon/identity/oauth2/util/OAuth2Util.java#L637 >>>> >>>> [2] - https://wso2.org/jira/browse/IDENTITY-5483 >>>> >>>> >>>> Thanks >>>> >>>> -- >>>> Rajith Vitharana >>>> >>>> Senior Software Engineer, >>>> WSO2 Inc. : wso2.com >>>> Mobile : +94715883223 >>>> Blog : http://lankavitharana.blogspot.com/ >>>> <http://wso2.com/signature> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >> >> >> -- >> Rajith Vitharana >> >> Senior Software Engineer, >> WSO2 Inc. : wso2.com >> Mobile : +94715883223 >> Blog : http://lankavitharana.blogspot.com/ >> <http://wso2.com/signature> >> > > -- Rajith Vitharana Senior Software Engineer, WSO2 Inc. : wso2.com Mobile : +94715883223 Blog : http://lankavitharana.blogspot.com/ <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
