(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).
The reason for this post is that EAA needs a good IDP to consume identities and do the job of controlling access at the edge of the Internet.
Good news is that NetIQ Access Manager brings everything EAA needs by offering a Risk Engine, MFA, Enterprise Class IDP, SAML2, …
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
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:
- 1/ Publishing NAM IDP without the help of EAA (using on-premise DMZ, Proxies, …).
- 2/ Publishing NAM IDP with the help of EAA. (Using EAA Cloud DMZ)
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
- Create a URL Rule to restrict access to path “/nidp”. This prevent any public access to other resources on this server. (NAM IDP may host some test portal or unexpected page that may be a security hole). Remember that everything targeted by the rule is DENIED (so by default everything is allowed).
- In advanced settings tab: leave everything by default except for Health Check Configuration.
- Set “type“: HTTPS and “Location”: /nidp/app/heartbeat
- Click on “Show Additional Attributes“
- Go to “Miscellaneous” and configure “Proxy Buffer Size” to 8kb. This is required because some NAM IDP xhr request contains a lot of headers and 4kb is not enough.
- 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:
- On the NAM Administration Console Dashboard, click on “Applications” in the left panel.
- 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.com
Do 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
- On the top menu of the admin console, click on “devices” -> “Identity Server”
- Click on “Update All” to deploy the new configuration.
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):
- On the landing dashboard page, click on the IDP Cluster link
- Click on the “SAML2” tab and create a new Service Provider Configuration.
- 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
- Go to “Attributes” tab and on the “Attribute set” select box, select <New Attribute Set>
- Type a name like “EAA User Profile” and click next
- Click the button “new” to create a new attribute map. Select a LDAP Attribute on the list which is unique and will be the username in EAA. (ex: sAMAccountName for AD, cn for other LDAP directory or email address).
Set the Remote Attribute field with the value: “NameID”
- (optional) Do it again for the LDAP attribute “memberOf” (or “groupMembership” for NetIQ eDirectory) and map it or remote attribute “Group“
- To finish the attribute settings, be sure to select and move all of them to the left column.
- Apply and go the “Authentication Response” Tab:
- Binding: POST
- Check “Unspecified” in “Name Identifier Format” column, set it as “Default” and choose “LDAP Attribute:cn” (or “LDAP Attribute:sAMAccountName“, …)
- Click “OK” to Save and exit the configuration
- Click “OK” again, the list of IDP server is displayed, “deploy” the configuration by clicking “Update All“.
- If NAM Server has Internet Access, you can use the EAA Login SP Metadata URL to do an automatic configuration. In this case, in step 3, choose “Metadata URL” in the Source selectbox and type the URL: https://<eaa-login-sp-fqdn>/saml/sp/metadata
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
- Tick “Sign SAML Request” and copy the public key of the certificate to a local file you can name “nam-eaa-sp-sign.pem”
- Save & Exit
Configuration in NAM:
- First task is to upload the public key of the Certificate Authority used by EAA Signing Certificates. In NAM Console go to “Security” -> “Certificates”
- Copy/Paste the following public key (EAA Signing CA)
- Then go to “trusted roots” -> “Import…” -> “Certificate data text” and paste the public key.
- Click OK to Save.
- Then go the IDP Settings by clicking on the IDP Cluster
- Go to the “SAML2” tab and click on the EAA Login SP (you previously created) link.
- Click on “Metadata” tab and on “Edit” then click the button “Choose a file” and upload the public key of the signing certificate: “nam-eaa-sp-sign.pem”
- 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“
- Create a new rule that will target DENIED users.
Ex: Group is NOT grp-eaa-remote (where grp-eaa-remote is the name of the group – CN or sAMAccountName attribute)
- 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)