This information was last reviewed in April, 2019, by Scott Cantor.

This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.

This is a page for documenting Shibboleth integration with OracleCloud.

I would imagine it can function as both IdP and SP but per usual this is about the SP functionality.

I found the platform really, really confusing, though the SSO features themselves are pretty vanilla, the problem is getting into the thing to start with and having the access to set it up.

This is my best attempt to explain the UI as I was able to grok it. It's probably wrong.

It seems to be divided into "identity domains" that are kind of like accounts in AWS or tenants in Workday, but each domain can have many services (again like AWS). The trick is that the SSO is at the identity domain level, but there's also a sort of top level cloud account login that seems to be linked to your Oracle.com "general" account by email address. If you're like me, you created a throw away Oracle account for whatever, and don't care what the password was. Now you will be given carte blanch account admin access based on the matching email address, so, umm, hey, change that password first.

At that point, you need to create, or have created, a user account and password in the specific Identity Domain, with admin rights there. It could be you don't need the top level access if you have this created for you but I didn't try that.

Anyway, having done that part, you should be able to access https://myaccount.cloud.oracle.com/mycloud/faces/dashboard.jspx to get a listing of services within domains. By clicking a service, you can get to a display with some details that include a My Services URL and triggers a request for a login using the per-domain credential.

From there, a new window opens and a menu drop down on the top left has a Users link. That link gets you to a domain-wide set of tabs, and one of those is the SSO Configuration tab. If you don't have the necessary admin rights, you can't get to that place and you end up lost and wandering around this thing for a while.

Identity Provider Metadata

Oracle can consume metadata as a one-time load, or you can set it up manually. I stuck with manual. The settings sometimes apply "on the fly" any time they're changed by an administrator, but I found that updating the signing certificate was not a reliable operation and it was "stuck" using the originally supplied key. The only way I was able to update that particular setting was to swap over to importing metadata to "clear" it out back to a set of options and then flip back to manual and edit anything needing cleanup. That seemed to internally reset the key based on what was in the metadata.

A snapshot of the dialog is here:

It has the usual stuff you'd expect. You won't need an encryption certificate, though it's possible it might do encryption during logout if you provided one. They support mapping users in by SAML Attribute so sticking with a transient ID and avoiding encryption to the IdP is best.

Note that the outbound requests it makes are HTTP-Redirect binding, not POST (that field is about the inbound SSO message binding).

Service Provider Metadata

You can click a button to Export Metadata and get a generally workable metadata file out for the IdP to load (it's static of course). They appear to use different keys for different domains but the same key for signing and encryption.

Profile Requirements

The SSO behavior is fairly standard except that it does sign its requests (doesn't seem to be optional) and it does require signed assertions (which they include as a flag in their metadata, which the IdP will honor).

They support SHA-256 but they use SHA-1 when signing themselves.

Logout

The SAML logout support does appear to work, though in two domains I have configured, one does the logout and one doesn't, and there are no differences in the settings, so there's some generic bug on their side I apparently hit in one domain.

Example Shibboleth Configuration

Refer to the RelyingPartyConfiguration topic and be cognizant that creating overrides for every service is generally an inefficient use of the software. Consider identifying common requirements across services and create overrides tied to multiple services that share those requirements, or that reference profile configuration beans containing common settings.

Required Profile Configurations

SAML2.SSO

Optional Profile Configurations

SAML2.Logout

Account Provisioning

I don't believe they do any in-band provisioning, just authentication of existing user accounts in the Oracle domain linked by user ID or email.

NameID Requirements

Oracle can use, but doesn't require use of, the NameID, so don't use it.

Attribute Requirements

You can map in users by arbitrary SAML Attribute name based on the Oracle User ID or Email fields in the user records, so standard IdP behavior should be fine.