Sometimes a fully transparent and automated identity and access management is the best solution candidate.
No additional components like bridges or manual intervention,
authentication and authorization fully controlled by leading IAM, e.g. the OnPremises IAM.

Several scenarios are feasible and different technologies available with OCI IAM/IDCS.
Here in this blog SAML JIT (Just in Time Provisioning = provisioning of accounts and authorization within the authentication process)
and SCIM for provisioning will be used.

 

The basic building blocks in an overview:


1) SAML JIT:
With this mechanism the configuration of the SAML IDP will be extended for provisioning of Accounts and authorization.
In IDCS these are 2 steps:
First define SAML IDP
then use REST API and extend this IDP (see sample at the end of the blog)
In IAM Domains this is one step approach as there is a brand new wizard:
https://blogs.oracle.com/cloudsecurity/post/oci-iam-simplifies-single-sign-on-administration

2) Provisioning or Synch of 2 or more IDCS/IAM domain instances with SCIM  
see previous blogs:
Provision IDCS/IAM Domain from a IDCS/IAM Domain
Synch IDCS with IDCS
Synch/Provisiong and SAML with multiple IDCS

 

If you sit in front of the configuration, some design considerations come up at the latest when you think about the flow with:


1. For SAML JIT:
Which Groups are needed to implement the intended authorization in IDCS/IAM Domains.
There are also some basic boundaries like no nested groups and/or no delete account via JIT
Besides the authorization there is also a possible e.g. delete process to consider so that a delete via UI or Rest will succeed.

A solution could be a top down approach:
each enterprise role will be a group which will be passed via JIT
if there are other roles which can not be aggregated each one of them will be a group
you can decide on authorizations also using attributes of user.

the bottom up approach will look at the process:
one group (not necessary in JIT, see next section) for general access to each target


2. For SCIM
SCIM offers provisioning (near in-time) and synchronization (schedule)
Here Provisoning is used as pattern to be able to react on SAML JIT which is an used based IAM as it is executed during login process
Within the provisioning you define the group mapping (per source and target) to define the permissions
this means you need to think about the group/attribute structure across all sources and targets

 

To illustrate this with a sample:

Setup:

Sample

 

Groups and group mapping:

Group Mappings

 

SSO control:

  • Source only allows IDP as login (IDP policy)
  • Target(s) are federated with source; the SAML SP config in Source is assigned to only the “General” group, so SSO is allowed only for these members
  • Each App can be configured allowing only the next IDP as Login (IDP policy), so a direct access of App will trigger the right flow
  • if the valid/active IDP policy contains only one SAML IDP then it will go to next IDP without user intervention. In case App3 is called directly user is redirected to leading IDP.

 

Use a more synchronos integration with the Target(s):

With the SCIM provisioning integration of the targets there may be some latency in update processes. Means e.g. group revocation is not in-time within the SSO process and may need some additional seconds. If updates are mandatory during the SSO flow for a target then SAML JIT can also be configured.  To get this:
– enable SAML JIT as described here with only dynamic group memberships; for this the IDCS source group names of source will be used.
– enable the SAML SP application in source IDCS/IAM who establishes the SSO between source and target for passing group memeberships:
go to SAML SP app for tab SSO; go for section attributes and add group memberships (see screen):

IDCS groups in SAML

 

Appendix IDCS Rest API for Configuration of SAML JIT.
Documentation: https://docs.oracle.com/en/cloud/paas/identity-cloud/rest-api/workingWithIDPs.html#unique_363937752
As a REST client is needed Postman could be used: https://docs.oracle.com/en/cloud/paas/identity-cloud/rest-api/UsingPostman.html
You need following Rest APIs for configuration:

  1. Search ID for IDP e.g via.:
    Get  {{HOST}}/admin/v1/IdentityProviders

  2. Get details as you need the references for the mapping in an attribute for step 4:
    Get {{HOST}}/admin/v1/IdentityProviders/{{idpid}}
    Look for “jitUserProvAttributes”: { “value”: “dccaf1128…..”,

  3. Configure SAML IDP for SAML JI
    Patch {{HOST}}admin/v1/IdentityProviders/{{idpid}}
     
  4. Configure Mapping
    Patch {{HOST}}/admin/v1/MappedAttributes/{{idpattributemapping}}
     
  5. The settings are documented in the link above, below a sample

How to find attribute, attributenames and groups from IDP?

  • Configure IDP in IDCS/IAM Domain
  • Initiate SSO with Browser tools open, go for sso statement and pick SAML Response
  • Decode SAML either with browser tools or with an external tool
  • search for subject (NameID) and the other attribute, grab the description and in cae of groups the values, e.g. in Azure SAML looks like:
    email adress attribute (here “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress):
               <Attribute Name=”http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”>
                    <AttributeValue>test03@mdadfdsfsdf.onmicrosoft.com</AttributeValue>
                </Attribute>
  • similar for groups, name of group mutli value fied “http://schemas.microsoft.com/ws/2008/06/identity/claims/groups”:
    and the values are needed for group mapping
                <Attribute Name=”http://schemas.microsoft.com/ws/2008/06/identity/claims/groups”>
                    <AttributeValue>2d0e6xxd054-42bxxx</AttributeValue>
                    <AttributeValue>440e6xxd054-42bxxx</AttributeValue>
                </Attribute>

Sample SAML JIT settings with User Attribute update, static group and dynamic group assignments (step 3);
Statement includes comments, please remove if you want to use it

{
  “schemas”: [
    “urn:ietf:params:scim:api:messages:2.0:PatchOp”
  ],
  “Operations”: [
    {
      “op”: “replace”,
      “path”: “jitUserProvEnabled”,
      “value”: true
    },{
      “op”: “replace”,
      “path”: “jitUserProvCreateUserEnabled”,
      “value”: true
    },
    {
      “op”: “replace”,
      “path”: “jitUserProvAttributeUpdateEnabled”,
      “value”: true
    },
    {
      “op”: “replace”,
      “path”: “jitUserProvGroupAssertionAttributeEnabled”, // group updates should be applied
      “value”: true
    },
    {
      “op”: “replace”,
      “path”: “jitUserProvGroupStaticListEnabled”, // use also static groups
      “value”: true
    },
    {
      “op”: “replace”,
      “path”: “jitUserProvAssignedGroups”, // the static group for each user, ID is IDCS/IAM group Id, one group
      “value”: 
       [
       {“value”: “998433b4a14e468e….”}
       ]
    },
    {
      “op”: “replace”,
      “path”: “jitUserProvGroupSAMLAttributeName”,
      “value”: “http://schemas.microsoft.com/ws/2008/06/identity/claims/groups” // name of group attribute in SAML response
    },
    {
      “op”: “replace”,
      “path”: “jitUserProvGroupMappingMode”,
      “value”: “explicit” // only groups from SAML are valid
    },
    {
      “op”: “replace”,
      “path”: “jitUserProvGroupAssignmentMethod”,
      “value”: “Overwrite”
    },
    {
      “op”: “replace”,
      “path”: “jitUserProvGroupMappings”, / mapping of IDP groups from SAML stetement to IDCS group IDs, here two
      “value”: [
   {
     “idpGroup”: “20a84240-0176-4…”,
     “value”: “aab0a1b70db34…”
   },
   {
     “idpGroup”: “071cec9c-7997-…”,
     “value”: “0274ccaa199f458..”
   }
     ]
   }
  ]
}
 
Sample for mapping with static and dynamic values for minimal IDCS User(step 4):
{
    “schemas”: [
     “urn:ietf:params:scim:api:messages:2.0:PatchOp”
 ],    “Operations”: [
     {
         “op”: “replace”,
         “path”: “attributeMappings”,
         “value”: [
                {
                    “managedObjectAttributeName”: “$(assertion.http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name)”, // name from SAML response
                    “idcsAttributeName”: “userName”
                },
                {
                    “managedObjectAttributeName”: “TESTJIT”, // static for quick test
                    “idcsAttributeName”: “name.givenName”
                },
                {
                    “managedObjectAttributeName”: “Azure”, // static for quick test
                    “idcsAttributeName”: “name.familyName”
                },
                {
                    “managedObjectAttributeName”: “$(assertion.http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress)”, // name from SAML response
                    “idcsAttributeName”: “emails[primary eq true and type eq \”work\”].value”
                }
 
            ]
        }
    ]
}