Identities with Inbound SAML/OIDC

By: Dennis Reichenberg user 07 Jun 2019 at 5:19 a.m. CDT

4 Responses
Dennis Reichenberg gravatar
Hi Gluu team/community, we are operating in a context, where we have the requirement that businesses might want to provide their own IdP. These businesses own specific resources in our software system and are strictly separated from each other (e.g. one business cannot see the resources of another business). From my understanding Gluu keeps track of the users identities based on some subset of user data and the corresponding IdP that the user has authenticated with. So e.g. when we retrieve the users ID token or the user info, we would be able to distinguish a user `John Doe <j.doe@example.com>` that authenticated with `IdP of Business A` and another user `John Doe <j.doe@example.com>` that authenticated with `IdP of Business B` based on their `sub` values. I was not able to verify this yet, so is this actually true? And on the other hand I'm wondering whether or not it would be possible to programatically find out what IdP the user came from via the OIDC API? This might come in handy when we want to immediately assign the user to the business that he is associated with on his first authentication. It feels a bit like we are going against the grain of OIDC with this, as I was not able to find an obvious way to achieve this, but on the other hand these businesses want to administer their users on their own terms with minimum effort. Thanks in advance! With best regards, Dennis
Debian 9.9
closed

Answers

By Dennis Reichenberg user 11 Jun 2019 at 9:23 a.m. CDT

Copy
Dennis Reichenberg gravatar
Hi, so we just updated our setup, and added another IdP to test this scenario. The inbound SAML server rejected the authentication from the second IdP, because the email address had already been associated with an existing user. See the following logs for reference: ``` 2019-06-11 13:39:34,001 INFO [qtp804611486-14] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - An attempt to supply an email of an existing user was made. Turn on 'emailLinkingSafe' if you want to enable linking 2019-06-11 13:39:34,002 INFO [qtp804611486-14] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport. attemptAuthentication. Authentication attempt was rejected ``` This is at least a bit soothing for us, as this removes the the possibility of confused identities once an identity has been established with our system, but this does still impose the threat, that a user from a third party IdP might be quicker than the user from the actual IdP. Is there any way to resolve this? Email suffix whitelists would probably be sufficient to get rid of this threat. E.g. add a whitelist entry for example.com to our trust relationship with IdP A to make sure that all the users with `@example.com` emails originate from their IdP. If another user attempts to authenticate from IdP B with such an email he would be rejected, because example.com is not whitelisted for his IdP.

By Mohib Zico staff 13 Jun 2019 at 9:20 a.m. CDT

Copy
Mohib Zico gravatar
>> that a user from a third party IdP might be quicker than the user from the actual IdP. >>> Email suffix whitelists would probably be sufficient to get rid of this threat. E.g. add a whitelist entry for example.com to our trust relationship with IdP A to make sure that all the users with @example.com emails originate from their IdP. Though I don't see any threat or things to resolve here but if we get request from customers on this, we will try to evaluate this 'Email whitelist' feature and/or pros/cons.

By Dennis Reichenberg user 14 Jun 2019 at 5:30 a.m. CDT

Copy
Dennis Reichenberg gravatar
Hi Mohib, > Though I don't see any threat or things to resolve here but if we get request from customers on this, we will try to evaluate this 'Email whitelist' feature and/or pros/cons. thank you for the reply. The more important question to me right now is, whether or not Gluu does provide us the or allows us to somehow map the information what IdP the user used to authenticate with. This would at least allow us to implement our own process, to prevent such identity conflicts and immediately find out whether or not a specific user should be activated in our system or completely disregarded.

By Mohib Zico staff 14 Jun 2019 at 5:38 a.m. CDT

Copy
Mohib Zico gravatar
>> The more important question to me right now is, whether or not Gluu does provide us the or allows us to somehow map the information what IdP the user used to authenticate with. Yes, `issuer` in passport config distinguish IDPs. - SAML Passport: https://gluu.org/docs/ce/3.1.6/authn-guide/inbound-saml-passport/ - OpenID Passport / Social: https://gluu.org/docs/ce/3.1.6/authn-guide/passport/ Also, you can generate a new custom attribute named 'issuerIDP' and map that information in Passport script. So, when users will come from any IDP; assertion / data will bear the value of Issuing IDP information.

Post an answer