The Complete Guide to Securing Your AEM Pages with Okta and SAML
Set up trusted access to your AEM content using SAML 2.0 and certificate-based authentication.
Some parts of your AEM site shouldn’t be public. Maybe it’s internal tools, partner content, or anything that only certain users should access. Instead of managing credentials inside AEM, it’s faster—and a whole lot safer—to hand that job off to a trusted identity provider like Okta.
In this guide, you’ll learn how to integrate Okta with AEM using SAML 2.0 and digital certificates. We’ll show you how to set up authentication so that only authorized users in your Okta environment can access protected AEM pages.
Let us show you how it works—using AEM Core Components and the sample page at at /content/core-components-examples/library.html on a publish instance.
Create Certificates
Before setting up the SAML 2.0 app in Okta, you’ll need to generate RSA public and private keys and a certificate. The private key will be used to sign SAML messages.
Since we’ll be enabling “Assertion Encryption” in Okta, let’s create the keys first.
Create AEM User
You’ll need a dedicated AEM user to handle authentication. In this example, we’ll create a user named “okta-user”.
Don’t forget to replicate this user to the publishers.
Create an App in Okta
To keep things simple, we’ll use a trial Okta account.
1. Go to your Okta admin console -> Applications
2. Click “Create App Integration” -> Next
3. Select SAML 2.0 -> Next -> Enter App Name, Logo (optional)
4. Create new App -> choose Web and SAML 2.0, App Name: okta-aem-test
5. General Settings
Single sign-on URL: ttp://localhost:4503/content/core-components-examples/saml_login
Audience URI: localhost:4503
The rest stays unchanged.
6. Attribute Settings. Here, map the user from Okta to the okta-user we created in AEM earlier.
7. Click Next -> Finish
8. On the “Sign On” tab click “View SAML setup instructions”
9. Download certificate here:
Finally, make sure you have the following ready:
- okta.cert file downloaded
- Identity Provider Single Sign-On URL: (https://trial-*******.okta.com/app/trial-******_oktatestaem_1/******/sso/saml)
- IdP Issuer (http://www.okta.com/****** )
- aem.crt, aem.key, aem.der, aem-pkcs8.der files created earlier
Assign users to the App
Now assign the users or groups who should have access to the AEM content.
Go to the Assignments tab -> Click “Assign to People or Groups” and select users or groups.
Upload certificates to AEM
You can configure this on the author instance and replicate, or set it up directly on the publish instance. For this guide, we’ll use the publish instance.
1. Add okta.cert file to http://localhost:4503/libs/granite/security/content/truststore.html (or do this on the author instance and and then replicate /etc/truststore/truststore.p12 to all the publishers (write down IP Alias))
IP Alias = certalias___1748861553223
2. Configure authentication-service user keystore: http://localhost:4503/libs/granite/security/content/v2/usereditor.html/home/users/system/authentication-service (upload files created before, enter SP Alias) (or do this on author and then replicate /home/users/system/authentication-service/keystore/store.p12 to all publish instances)
SP Alias = local-publish-alias
Make sure the /etc/truststore and /home/users/system/authentication-service/keystore/ nodes exist (with the same keystore password) before replication
At this point you should have:
- IP Alias: certalias___1748861553223
- SP Alias: local-publish-alias
- Keystore password
Prepare content
Ensure the /content/core-components-examples/ path is replicated to your publish instance before testing.
Apply OSGI config
It’s time to add the OSGi config files to your project:
/ui.apps/src/main/content/jcr_root/apps/***/config.publish/org.apache.sling.security.impl.ReferrerFilter.xml
ui.apps/src/main/content/jcr_root/apps/***/config.publish/org.apache.sling.engine.impl.auth.SlingAuthenticator.xml
ui.apps/src/main/content/jcr_root/apps/***/config.publish/org.apache.sling.commons.log.LogManager.factory.config-saml.xml
ui.apps/src/main/content/jcr_root/apps/***/config.publish/com.day.crx.security.token.impl.impl.TokenAuthenticationHandler.xml
ui.apps/src/main/content/jcr_root/apps/***/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler-eb4f0db6-ea88-4905-9e17-0bd22a38feb4.xml
Testing
That’s it! You’re ready to test.
Now open “http://localhost:4503/content/core-components-examples/library.html”. You should be redirected to Okta automatically:
After entering your username, password and security code, you’ll see the following page:
Important notice
If you’re getting a “java.security.InvalidKeyException: Illegal key size” exception, you’re likely using a version of Java that doesn’t support strong encryption by default.
To resolve this:
- Use Java 9 or higher, or
- Install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files (available from Oracle).
For more info, see: InvalidKeyException Illegal key size – java
Further Steps
This setup covers Okta integration on a publish instance only. It doesn’t yet account for Dispatcher configuration.
To allow SAML login requests through Dispatcher, you’ll need to allow POST requests to /saml_login.
In your filter config, add:
dispatcher/src/conf.dispatcher.d/filters/filters.any:
Was this article useful for you?
Get in the know with our publications, including the latest expert blogs
End-to-End Digital Transformation
Reach out to our experts to discuss how we can elevate your business