Joao,
If your Identity Provider is Google, it will be using pure OIDC. If it is another "social provider" (like Facebook) it may be using OAuth 2.0 + proprietary API calls. Verify Access can manage both of these types of provider with its OIDC Relying Party capability.
When Verify Access is a Relying Party for OIDC it is configured in the Federation add-on. You must first configure the "federation" as an OIDC Relying Party and then add a "partner" for each Provider.
The Identity Mapping that you need is configured in the "Identity Mapping rule" for the partner definition. You can configure a mapping at the federation level too but it is overridden by any rule configured at the partner... usually you'll need a different rule for each partner.
The mapping rule is called after tokens have been received from the Provider. For authorization code flow that means that authorize flow has completed and token endpoint has been called to get tokens.
When you're working with a pure OIDC provider (like Google), the mapping rule only has to perform identity mapping. The core functionality will have already validated the received JWT Id token and will make the claims available in the STSUUSER object that the identity mapping receives as input. The built-in "OIDCRP" mapping rule will work just fine. You can build on it if you need more functionality.
When you're working with an OAUTH+API provider (like Facebook) you don't send specify the oidc scope in the RP configuration. This tells Verify Access that this is really an OAuth flow and not a full OIDC flow. In this case the mapping rule will only receive an OAuth token. The mapping rule will need to make the required API calls to the provider itself (using HTTPClient Helper) and then extract required data from the response and then perform any required mapping.
I have an example mapping rule for Facebook on GitHub here:
https://github.com/jonpharry/labfiles/blob/master/oidc/facebook.jsThere's quite a lot going on in that rule and should give some good examples of what you can do.
Mapping rule doesn't have to do LDAP search if there's a programmatic way to convert from claims coming from provider to a valid local user. If you wanted to do a lookup in LDAP as part of the mapping that is possible. You can use the UserLookup helper to do that. I don't have an example of that to hand but I think that there have been blogs on this elsewhere. Maybe someone else has a pointer.
Claims from the provider are not automatically saved to the local user registry - usually these attributes are just asserted for the current session but not stored. If you want to save the attributes during the SSO flow you'd have to use the UserLookup helper to do this. You could search, create a new user if necessary, or update attributes.
Not sure what you mean by "application" when you ask how it gets the username. The Reverse Proxy gets the username in different ways depending on the Point of Contact configuration. Usually its an HTTP header as part of EAI. How a target application gets information from the Reverse Proxy is independent of the authentication method (local/federation/whatever). Usually you would pass down to the application as HTTP headers. You can send IV_CREDS but that is a proprietary format which implies some SDK on backend which is not often the case any more. More usual now to send individual claims as HTTP headers - or to send a JWT downstream.
I hope this helps. Maybe you can use the examples above to help your understanding... ask more questions based on these if you need to.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Mon June 21, 2021 01:10 PM
From: Joao Goncalves
Subject: Identity mapping Google user to Local user
Google and other Identity providers use OAuth and OIDC.
I need to understand in which step in the OAuth or OIDC relying party, must the identity mapping occurs.
So, the user tries to access a protected resource, and it is redirected to Google for authentication.
ISVA, as the OAuth relying party, issues the token endpoint, to retrieve user data which, according to the google implementation (https://accounts.google.com/.well-known/openid-configuration) returns multiple data includind iss, sub, email, given Name,and more information.
ISVA now, must map the authenticated user to the local registry, using a Identity Mapping Rule. How is this process done?
- Does the ID mapping rule need to do a ldapsearch, to get the correct user?
- How does the Google user data, e.g. Google Email, Given Name, Family Name or any other attributes that I can use to map the google account to the username gets loaded in the Local User registry?
- How does the application gets the username (IV_CRED) I believe!
In which step is the Identity Mapping rule invoked?
Is my reasoning correct? Or does it have any flaws on my understanding on how the process gets executed?
------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------