With a couple of tweaks, OpenAthens LA can be used to sign users into Adobe.
- Access to the Adobe enterprise dashboard
- Some test users already set up in the Adobe dashboard as federated
- Access to your OALA admin console
- Depending on approach, you may need command line access to your runtime servers
Configure Adobe enterprise dashboard
- Under the identity section, claim your domain. Follow their instructions (should be linked from the identity section). This can take a while as you need to add a token to your DNS record for automatic validation and then wait for manual verification.
- Once claimed you can
Upload your IdP certificate. This is the x509 signing certificate from your metadata. Copy and paste it into a file as follows including the begin and end parts:Example certificate
IDP Issuer = your entityID, e.g. https://idp.yourdomain.com/oala/metadata
IDP login URL = your sso address e.g. https://idp.yourdomain.com/oala/sso
IDP binding: select HTTP-REDIRECT
User Login Setting: This guide will use email address, but choose what matches the users you have set up in the dashboard.
Download metadata. Do so and save it for later (download doesn't work in Firefox at the time of writing)
Configure OpenAthens LA
Adobe require the following attributes be released:
You will also need to release the email address as a different attribute that can be selected as the NameID of type:'unspecified'.
Their metadata is not published, only available as a download from the Adobe dashboard and is unique to you. This means you will need to either host it somewhere yourself (must be visible to both the admin console and the runtime server(s)), or manually add it to the runtime.
If you are hosting it somewhere:
If you need to manually add it to the runtime:
- ssh to the runtime
create a file with a .xml extension in the /usr/share/atacama-platform/metadata folder:
- paste in the metadata you downloaded from the Adobe dashboard
- Exit the editor saving changes
- Repeat for each IdP runtime
Create four datastore attributes:
The first three must be exactly those names. The last can be any name, or be an existing attribute holding the end-user's email.
Create a new release policy (Configurations > 'External' > Attribute release)
- Call it something such as 'Adobe'
- Apply policy [when] [service provider] [matches] and paste in the entityID that appears in the Adobe metadata. If you are hosting it, the entityID can autocomplete. If you have manually added the metadata to the runtime(s) you will need to copy and paste it from the metadata file. You could also use [contains] 'https://www.okta.com/'
- Add all four of the attributes to the policy and tick their release boxes
These options will ensure that only this resource is sent the email as the NameID - other resources will use the default and not be affected.
Advanced option tab changes
Adobe need the email to be send as the NameID rather than the default targetedID value. This is why there are two email attributes. To set this go to the advanced options tab and set:
- User identifier: emailAddress (or whatever your other email address attribute was, just not the one called 'Email')
- User identifier format: leave as 'unspecified'. If you have data in this field, delete it and hit apply before you move focus to any other field.
Publish and test
- Click the publish button.
- Try access to Adobe with a user that is known to have matching details set up at the Adobe end.
- Once it's all working you can start switching any existing users over to the federated login in the Adobe dashboard.