In OCI an integration of external SSO Environments, either in other Clouds or OnPrem, custom or vendor based, is possible. OCI supports this integration based on standards like SAML2, OpenIDConnect and others. For more information see: https://docs.oracle.com/en-us/iaas/Content/Identity/federating/federating_section.htm
Several SSO integrations can be configured in parallel, so no decision upfront which SSO is the right one. Different configurations allow to define which SSO or authentication method will be relevant for which users and which applications. In addition, it can be configured how MFA should apply and if risk-based aspects should be considered. The SSO is also sensitive on the network zones if configured. The different mechanism are described in the corresponding sections of https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm.
Let’s assume for a SSO integration SAML2 has been selected, e.g. for Azure. SAML contains two parties, the Identity Provider (IDP) who is responsible for the Authentication and the Service Provider (SP) which relies on the Authentication which is assured from the IDP. Every SAML integration relies on certificates for signing the requests. This is defined by the SAML standard and is the mechanism, besides the Entity ID, to build the trust between the SAML IDP (in the sample Azure) and SAML SP (here OCI Console, the UI of OCI).
Certificates have an expiration date, which implies after expiration the SSO will not work any longer. Typically, the Administrator will get notifications about upcoming expirations. Standard expiration on Azure is for an Enterprise Application 3 years. The Azure Enterprise Application is the integration mechanism for SSO to e.g. OCI. Azure shows expiration like this in the Applications screen:
(here a sample with one already expired and another on next year)
Besides the expiration of a certificate there are other cases like breaches, which also would lead to exchange the certificate. First step is then to create a new certificate. E.g. creation is possible within Azure Enterprise Application in the section SSO configuration, section SAML Certificates.
The next step is to pass the new signing certificate to OCI. The signing certificate usually can be exported “standalone” in different formats or within the metadata.xml. Metadata.xml is the file which describes the SAML IDP or SAML SP in the standardized format with various sections on Authentication aspects like endpoints, certificates, attributes, signing, encryption etc..
Depending on your OCI tenant the exchange and/or check can be achieved in different ways. Possible with UI or CLI/API. The API includes several supported languages e.g. terraform. The native API is REST based. See for API usage: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/devtoolslanding.htm
Tenants without Identity Domains
a. OCI native Federation
Here sample of exchange in an existing federation. Screen is from IDP config:
Here a sample code snippet using terraform*. Compartment id is tenant id, meta.xml is the metadatafile of the IDP (e.g. Azure):
resource “oci_identity_identity_provider” “Azure” {
compartment_id = “ocid1.tenancy.oc1..aaaaaaaatzrmon5xxxxx”
description = “Azure Federation”
metadata = file(“${path.module}/meta.xml”)
metadata_url = “null”
name = ” Azure “
product_type = “ADFS”
protocol = “SAML2”
}
Remark: Be aware that the plan only updates or creates the one IDP, sample plan output:
Plan: 0 to add, 1 to change, 0 to destroy.
If a terraform state file is not available, the import statement can be used to tell terraform that there are already resource (here IDPs) and the one has to be updated. Sample for one IDP:
import {
to = oci_identity_identity_provider.azure
id = “ocid1.saml2idp.oc1..aaaaxxx”
}
In case of an error, the messages are passed through from native OCI API which also could be used. E.g. IDP with same name already exists.
For the check:
As the OCI UI does not show expiration in the IDP config, an extraction with CLI is the quickest way. Open a cloud shell (=nothing to install, works within tenant) and do a
List all IDP configs by using the tenancy OCID, marked as deprecated but works*
oci iam identity-provider list –compartment-id ocid1.tenancy.oc1..aaaaa…
https://docs.oracle.com/en-us/iaas/tools/oci-cli/3.43.2/oci_cli_docs/cmdref/iam/identity-provider/list.html
or go for a specific one by refering to the OCID of the IDP, marked as deprecated but works*
oci iam identity-provider get –identity-provider-id ocid1.saml2idp.oc1..aaaaaaaa4….
*) for old tenants and the default domain, for IDCS, IAM domain based see next chapter
Result is an output with IDP(s) described in JSON. Within the metadata field the certificate sections can be found.
{
“data”: {
…
“id”: “ocid1.saml2idp.oc1..aaaaaaaaxxxx”,
….
“metadata”: “<?xml version=\”1….”
“metadata-url”: “null”,
“name”: “Azure”,
“product-type”: “ADFS”,
“protocol”: “SAML2”,
“redirect-url”: “https://login.microsoftonlixxxxxx”,
“signing-certificate”: null,
“time-created”: “2024-06-18T18:18:43.968000+00:00”
},
}
Grab metadata field in an editor and search for signing attribute in IDPSSODescriptor as there a several sections with “signing”. Specification of the whole structure can be found at oasis.
The value of the X509 is encoded and starts like this:
<X509Certificate>MIIC8DCCA….
You can decode with base64 (then you need to transform the timestamps) or store the payload without envelopes “<..>” as file with extension .crt (security certificate) to open it in a browser with a double-click. Looks like this:
Here after a new created and exchanged signing certificate:
So a quick check of an expiration is possible. With this it’s easy to verify that there is no upcoming problem with expiration or if the update was successful.
b. Via Identity Cloud Service (IDCS)
Screen for exchange looks similar which allows a browserbased upload of metadata.xml.
The check is done with IDCS API which require configuration of an OAuth Client and use of a REST Client. See e.g. sample tutorial for postman https://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/idcs/idcs_rest_postman_obe/rest_postman.html
Retrieval via
{{HOST}}/admin/v1/IdentityProviders/{{IDPID}}/?attributes=metadata
Or as CURL
curl –location ‘https://idcs-9f7a0bfxxx.identity.oraclecloud.com//admin/v1/IdentityProviders/9e6c90xxxx?attributes=metadata’ \
–header ‘Authorization: Bearer eyJ4NXQjUzI1NiI6IllMOFhNSjItUnNsOU5nRWExxx‘
See documentation: https://docs.oracle.com/en/cloud/paas/identity-cloud/rest-api/api-saml-identity-providers.html
Output should look like:
{
“metadata”: “<?xml version=\”1.0\” encoding=…”
“type”: “SAML”,
“id”: “9e6c905xxx”,
“partnerName”: “Azure”
}
Then grab the metadata and go for the IDPSSODescriptor section with “signing” as in the case before.
Tenants with Identity Domains
The Identity Domains allow the upload of the new metadata also in the UI
After change, the check of the expiration works with identity domain specific API. So open Cloudshell and use CLI. Here to retrieve all IDPs the get the ID as the ID is not shown in the UI. The endpoint parameter is the URL of the Identity Domain:
oci identity-domains identity-providers list –all –endpoint https://idcs-9a77xxx.identity.oraclecloud.com:443
More in documentation: https://docs.oracle.com/en-us/iaas/tools/oci-cli/3.43.2/oci_cli_docs/cmdref/identity-domains/identity-providers/list.html
From the result grab the metadata field content an proceed like in the section before.