Integrating Akamai EAA and Access Manager using SAML2
(Direct link to download Akamai EAA Connector for NAM:
- v1.0.5: EAA Connector for NAM)
Akamai Enterprise Application Access (EAA) is a hybrid (cloud and on-premise) solution that shifts the attack surface of a DMZ in a secure cloud bastion.
The whole idea is to control and secure access without any distinction between internal and external users, following the new paradigm of the Zero Trust model.
But in brief, EAA is a big cloud reverse proxy using an on-premise gateway(s) to make the bridge with the enterprise (without opening anything on the firewall).
- Trial access of testing: https://content.akamai.com/us-en-pg9050-eaa-request-trial.html
Thanks to federation and SAML2 protocol both NetIQ Access Manager and Akamai EAA can be integrated together in hybrid cloud access management project.
And for having worked a lot on NAM these past years, EAA offers something that everyone who already deployed NAM in a complex environment would love: Publishing securely, the NAM Identity Server on the Internet in a matter of minutes. And this way, bypassing the issues on firewall/proxies/waf/vlan/router/... that are a common pain.
Well of course this will leverage a discussion of offloading part of the DMZ or not, but let's not drown in it and walk through some configurations to show what it does.
- EAA (SP) Configuration
- NAM (IDP) Configuration
- Optional: Using Signed SAML Request
- Test & Troubleshooting
- Chain of Access Control
- Admin access to NetIQ NAM Admin Console
- Access to the EAA Management Console (for a trial account: https://content.akamai.com/us-en-pg9050-eaa-request-trial.html)
- SAML Trace extension in your browser for further testing
- Ex. for Chrome: SAML Message Decoder - Chrome Web Store
- (optional) NetIQ NAM Connector for EAA for easy deployment: EAA Connector for NAM
- (optional) Certificates to upload on EAA if you wants to use your own domain + HTTPS
Providing remote access to applications through EAA also require to provide a remote access to NAM IDP as it will serve the authentication page and the SAML endpoint to client web browser.
This brings two architecture cases:
In this article I will explain the configuration using the case 2: Publishing NAM IDP with the help of EAA.
Expected end-user access flow
Using the above schema, here is the access scenario of end-user client accessing "app1.go.akamai-access.com" (EAA edge proxy of the application) for the first time in his session. This is basically a classic SAML SP-Initiated scenario, but it's always good to write down some basics to be sure we understand every requests happening there.
- Client send a HTTP GET request to EAA EDGE Proxy "app1.go.akamai-access.com". This resource is protected by EAA and need authentication, the EAA EDGE Proxy answer the request with a HTTP Redirect to "nam-sp.login.go.akamai-access.com" which is the Login "Service Provider" configured to request and consume and authentication delegate to the third party NAM IDP.
- Client is redirected to the Login SP "nam-sp.login.go.akamai-access.com", it will then generate a SAML Authentication Request and add it in the http headers of a new HTTP Redirect. This answer from the Login SP will redirect the client to the NAM IDP published URL: login.mycompany.com (CNAME to the EAA Edge Proxy of the NetIQ NAM IDP Server)
- Client is then redirected to the NetIQ NAM IDP Server login.mycompany.com. The IDP use the SAML Authentication Request sent in the headers to know which service provider send the request and if the request is valid (allowed SP, time, signature, ...). NAM IDP then authenticate the client (could be login/password, MFA, ...) using the Local Directory to match the Identity. In case of a successful authentication, the client is redirected back to the EAA Login SP with a HTTP POST Redirect. The POST Redirect contains a Signed SAML Response (aka. SAML assertion) with the required information (username) and the optional information (groups).
- Client is redirected to the EAA Login SP "nam-sp.login.go.akamai-access.com". It validate (signature, time, ...) and consume the SAML Response to create a new session in EAA Cloud for the authenticated user.
- Client is finally redirected to the EAA Edge Proxy of the application "app1.go.akamai-access.com" with a EAA Session Cookie. The request can now go through the cloud proxy to the EAA Connector and from the EAA Connector to the Application. (no SSO configured in this example, meaning the user may have to authenticate again at the application level)
NAM IDP Server is listening by default on TCP Port 8443 so I suggest you to do the mapping to TCP 443 in the EAA Application Configuration and avoid/remove any previous solution like extra proxy or script to do it.
Publish NAM IDP with EAA
In your EAA Management Console:
- Create a new application (Type HTTP Custom)
- Set application server IP/FQDN and use Port 443 or 8443 (to check with the responsible of the NAM Server)
- Set Internal Host (name) to the strict exact name of the NAM Server published hostname. (ex: login.mycompany.com)
- "Use your domain" and type the same host name for external (ex: login.mycompany.com). This will avoid rewriting by EAA proxy because not everything can be a rewrite in a SAML Request. The problem is that the content of the SAML assertion in encoded in base64 and so EAA will not rewrite internal name with external name.
- You can use self-signed certificate
- In Authentication Tab: DISABLE authentication. As NAM IDP is the authentication service there is no prior authentication to add.
- In Services Tab: Enable "Access Control" and click on configure rules
- In advanced settings tab: leave everything by default except for Health Check Configuration.
- Click on "Show Additional Attributes"
- Go to deployment and deploy the NAM IDP Application.
Configure SAML 2.0 Federation between NAM and EAA
- A NAM IDP server up and running
Step 1: Configure the EAA Login SP
- Using your web browser or a CLI tool like curl, download the xml metadata of the NAM IDP Server
In your EAA Management Console:
- Create a new Identity Providers (EAA Login SP - Type SAML)
- You can use a Akamai domain
- In "Authentication Configuration", set "URL" to https://<nam-idp-fqdn>/nidp/portal. This is a link used by EAA to send a user to the IDP landing page, I did not found yet a scenario were it is used because in a federation scenario (SP Initiated login or IDP initiated login), only the URL declared in the IDP metadata matters.
- Set also "URL Logout" to "https://<nam-idp-fqdn>/nidp/app/logout". When called this link will trigger a "Single Logout", meaning it will kill the IDP user session so further application saml request will trigger a re-authentication. Idem as previous settings, not directly used in a federation scenario as everything is already declared in the metadata.
- Do not tick "Signed SAML Request" for now, the activation of this settings will be explained later.
- Upload IDP Metadata File - Choose the metadata.xml file you download in the preparation step from the NAM IDP Server.
- Save & Exit
Step 2: Configure NAM IDP
To configure NetIQ Access Manager IDP, there is two ways:
- Using a ready-to-deploy "EAA Connector for NAM" available attached to this article, and I hope soon in the NetIQ global catalog
- Manually. Settings all parameters but accessing advanced settings also.
Solution a) Connector
This solution is more adapted if you don't know much about NAM IDP configuration as it is easier.
In NAM Administration Console:
- Then click on "+" and "import Application from file". Select the EAA Connector for NAM zip file attached to this document (EAA Connector for NAM).
- The wizard configuration start on right panel, go to tab "Application Connector Setup" and type the URL of the EAA Login SP you configured in EAA.
For instance: https://my-nam-sp.login.go.akamai-access.comDo not upload a signing certificate (we will test & activate signed SAML Request later)
- Click on the tab "Attributes" and decide if you wants to send group membership (by default it send all user's groups) along with the username to EAA.
Choose the LDAP Attribute that will be used as "username" by EAA, it can be "LDAP Attribute:cn" or "LDAP Attribute:sAMAccountName" (for AD) or email address, ...
- Click "Save" to finish
Solution b) Manual
In NAM Administration Console - https://<nam-console>:8443/nps (be careful, most of the time NAM Administration Console is not hosted on the same server, check with the admin team):
- Provider type: General
- Source: Manual Entry
- Name: <display-name> (ex: EAA Login SP)
- Provider ID: https://<eaa-login-sp-fqdn>/saml/sp/response (ex: https://my-nam-sp.login.go.akamai-access.com/saml/sp/response)
- Post Consumer URL: https://<eaa-login-sp-fqdn>/saml/sp/response (ex: https://my-nam-sp.login.go.akamai-access.com/saml/sp/response)
- Click "Next"
- Signing Certificate Display should be empty as we did not yet setup one. (will do later)
- Click "Finish" and then click on the newly created SP on the list
- Type a name like "EAA User Profile" and click next
- (optional) Do it again for the LDAP attribute "memberOf" (or "groupMembership" for NetIQ eDirectory) and map it or remote attribute "Group"
- Click "OK" to Save and exit the configuration
Optional: Using Signed SAML Request
Signed SAML Request allow NAM IDP to verify the authenticity of the EAA Login SP sending a request. So the request cannot be forged by someone else as only the EAA Login SP will have the private key of the signing certificate.
This is not a mandatory feature but a nice to have. Because what matters first is the SP trusting the IDP, meaning the IDP authenticity is the most important. As it will tell EAA the identity and the authorization info of the client, the trust has to be strong or everyone could stole any identity by faking some SAML assertion.
(Remark: both SHA1 and SHA2 hash algorithm are available, the default is SHA2)
Configuration in EAA:
- Edit the EAA Login SP (Identity Providers) in EAA Management Console
- Save & Exit
Configuration in NAM:
- Copy/Paste the following public key (EAA Signing CA)
- Click OK to Save.
- Click OK to Save, OK again and then "Update All" to deploy the modification on IDP Server(s).
Configure EAA Edge Proxy (Application)
In order to test the federation set between NAM and EAA, you have to configure at least one application that will be accessible only if authenticated against NAM IDP.
To do so, go in EAA Management Console:
- Edit a "Application"
- Go to "Authentication Tab" and assign the EAA Login SP (NAM Identity Providers) you created earlier
- Save and deploy
Chain of Access Control
In order to provide optimal authorization and do the full "chain of access control", EAA should also enforce some rule to prevent access to certain applications.
To achieve this:
- NAM IDP Authenticate and do the first access control: The risk engine decide how to authenticate the user or if it should be denied access based on Geo, Time, Headers, Device, History, Groups, ... This allow a global access control to EAA.
- NAM IDP send groups/roles/.. or any (virtual) attributes containing more precise authorizations for the application published through EAA.
- EAA store the info in the user session and apply a specific access control rule for each application (Allow or Denied access).
- User's group are sent by NAM IDP
To do so, go in EAA Management Console:
- Edit a "Application"
- Go to "Services" tab and enable "Access Control"
- Click on "Configure Rules"
- Save and Deploy
Tests & Troubleshooting
- Capture SAML Messages with an extension in your browser
- Check time, signature, attribute syntax, NameID, ...
- On EAA side, errors are displayed straight in the browser (like time issue on SAML Response)
- EAA Online Quickstart: https://community.akamai.com/docs/DOC-7213-enterprise-application-access-quick-start
- EAA Connector for NAM 1.0.5: EAA Connector for NAM