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? 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> >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
