Typically enterprises have an Identity and Access Management (IAM) established. Primarily due to reasons like cost savings in help desk, quicker on-/off-boarding of employees, introducing provisioning workflows and approvals. Ease of use through SSO may be the compelling event for your users, adjusted authorizations for your IT Security. If these ‘soft’ arguments would not have been relevant enough then the compliance topic was usually the main driver to introduce an IAM.
It didn’t matter if the compliance is enforced through laws, regulations or data minimization / least privileges requirements; you would end up with an IT based solution to get the status-quo of authorizations at any time and you can enforce the SoD (Segregation of duties), the approvals and the recertifications.
Oracle has a long-proven history in this market segment, with On-Premises products like Oracle Identity Governance and Cloud Services – just in case you think about changing your IAM solution; but this is not the topic here.
So let’s assume there is an IAM is in-place.
Next assumption is that the IAM should be extended for new or further cloud services for which the current IAM might not be the best choice. Let’s assume for a CX system or some cloud native applications (applications is used in the following as general term). Several reasons may impose themselves like there is no ootb (out of the box) connectivity to the new services, the ‘new’ users are of a different type and a mix is not appropriate, it’s too expensive or complex to extend the existing solution etc.
Nevertheless the new applications need authentication and authorization and some are already pre-integrated in an IAM of the provider like AWS, Azure, Oracle… This may already reduce the points of integration and act as an integration hub, using this term in the following.
If it is the case that you have more than one commercial or custom (e.g. build on open source) provider the connectivity would have to integrate several identity hubs. In this case an identity broker architecture could play a role to design this connectivity.
So you end up in one of the following architectures:
Following architecture connects one other Identity Hub. IAM includes IDM (Identity Management) and AM (Access Management / Enforcement / SingleSignOn). The existing IAM is the broker for the IAM hubs and the IAM hubs can be broker for applications which have an additional integrated IAM (like CX). So they play two roles.
In case of multiple new IAMs you may get this one with reduced granularity without the applications/spokes:
In case with more than one ‘existing IAM’, e.g. several customers integrate their IAM the architecture will extend to a n:m correlation. Here one hub connects a further one and one cloud tenant can contain more autarkic IAMs (Oracle OCI can do this with IDCS stripes and IAM Domains):
In every architecture the technical requirements are the same:
- Establish SSO for the authorized users (not every user is allowed to use every application, not every SSO login is allowed for every application)
- Manage user and authorizations, either manual in Hubs or automated through existing IAM
From a compliance and user-management standpoint it’s obvious that automation would be the preferred solution. From an implementation point of view integrations with standard protocols would be preferred. With this in mind the integration candidates are reduced to SAML, OpenID Connect and SCIM. SAML with JIT (just in time provisioning) can address both, SSO and Provisioning. As these standards have a relevant history most of the IAM solutions, providers, opensource and applications usually support these protocols. Just a remark: there are other valid mechanisms like API calls or Synch (File, LDAP) available which are not considered here.
A quick view on SAML JIT
SAML (Security Assertion Markup Language) is an open standard for authentication and authorization between an identity provider (IdP) and a service provider (SP). JIT (Just In Time) creates or updates accounts in the same flow during the authentication process. So if the authentication is successful then the account was created. The necessary information was provided in the same SAML response statement, the assertion. The additional information are attributes from the user and groupmemberships. Depending on the implementation groups are created on the fly.
Using SAML with JIT simplifies the process of adding new users to a further IAM, reduces manual intervention and improves security by centralizing the authentication and usermanagment process at the IdP. Caveat with SAML JIT is you can’t deactivate or delete users. To solve this either go for SCIM or do a mixed config; allow only updates with JIT and do create/delete/deactivate with SCIM or API Calls.
To get a practical approach Oracle IAM/IDCS is used as IAM hub. This blog follows the IAM Domain approach and focuses on SAML JIT. This reduces the configuration efforts to one integration per IAM.
- Further Reading for SCIM vs JIT can be found here: https://www.ateam-oracle.com/post/just-in-time-vs-scim
- SAML JIT with IDCS can be found here: https://blogs.oracle.com/coretec/post/saml-jit-and-multiple-idcsiam-domain-instances
Using SAML Configuration at the source in case of JIT requires that groups are passed in the SAML statement. There are three things to consider:
- Configure SAML to pass groups at all; this requires an extra step in the IDP. The section in the SAML statement which contains the group gets a name which has to be recognized by the Service Provider (SP), here IAM Domains.
- Restrict the number of groups as the SAML statement has a limitation because passed in http header; easiest config could be use assigned groups to SAML application. Only the groups assigned to user who is doing the SSO will be passed, not all.
- Think about if you want to have one or more default groups for any successful SSO to grant user access.
If you do not know the group section of SAML statement or how the groups are referenced (by ID or name) you can debug with any browser the SSO login and decode the SAML to see these values. The browser has development tools (ootb menu), use network traffic (preserve logs) and search for sso or login. Here go for the SAMLResponse and decode.
Configuration options and setup in IAM Domain:
If you already have a working SAML IDP configured you can jump to step 4.
1. Create and Configure SAML IDP: select domain
Here an extra Identity Domain is used which is created in a subcompartment to also illustrate that users can be physically separated in one tenant.
2. Create SAML IDP:
This requires the metadata.xml from your IDP; metadata of IAM domain can be retrieved within this config and has to be uploaded to your IDP.
Nice tutorial for Azure can be found here: https://docs.oracle.com/en-us/iaas/Content/Identity/tutorials/azure_ad/azure_ad_tutorials.htm#azure-overview
Go for menu Security(1) then Identity Providers(2) and then Add IDP/SAML(3):
3. Configure SAML IDP:
give it a name/next(1), upload metadata/next(2), adjust mapping/next(3) and press create IDP (Button after pressing next in the following screen which is not shown)
And do the rest of config to enable IDP as shown in various documentations and blogs. Test if SSO works. A User which matches has to be in this IAM Domain upfront, default matches against IAM username, typically the email is used for this. As screen shows can be adjusted.
4. Select IDP for SAML JIT config
choose Configure JIT(1), enable JIT(2) and adjust JIT settings (3,4,5)
For 3 select the intended activity after successful authentication to create and/or update the user
For 4 specify the attribute name for the SAML statement. The user will be created with these values IAM Domain needs at least three attributes for creating a user: username, name and email. Azure SAML looks for email:
<Attribute Name=”http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”>
<AttributeValue>test03@mdadfdsfsdf.onmicrosoft.com</AttributeValue>
</Attribute>
NameID is from SAML SSO the username so this has to map for successful SSO, others could be chosen.
For 5: this is only relevant if you want to manage authorizations based on group memberships. After toggling the button (1) the section of the screen switches to
For 2 specify in SAML statement the name of the section which contains the groups assertions, typically groups in case of Azure http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
Behaviour is either replacing assigned groups from SSO before or merge (=add).
Looks like this:
Toggling this button enables you to specify default group memberships like this if you add one:
That’s all now you’re ready to test. If this does not work you can debug you SAML response and check the references.
This mechanism can also be used to create/update users from IAM domain to IAM domain and/or IDCS. In this case you have to configure the OCI SP to deliver the groups, because default behaviour in OCI is not to pass groups in SAML response.
Documentation IAM Domains with JIT:
https://docs.oracle.com/en-us/iaas/Content/Identity/identityproviders/manage-identity-providers.htm#usingconsole