(Direct link to download Akamai EAA Connector for NAM:
- v1.0.5: EAA Connector for NAM)

Introduction

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.
https://securityintelligence.com/the-zero-trust-model-for-living-in-a-hacked-world/

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).

• • More info: https://www.akamai.com/us/en/products/cloud-networking/enterprise-application-access.jsp

• • 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.

Summary

1. 1. Requirements

1. 1. Architecture

1. 1. EAA (SP) Configuration

1. 1. NAM (IDP) Configuration

1. 1. Optional: Using Signed SAML Request

1. 1. Test & Troubleshooting

1. 1. Chain of Access Control

1. 1. Links

Requirements

• • 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

Architecture Choices

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.

1. 1. 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.

1. 1. 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)

1. 1. 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).

1. 1. 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.

1. 1. 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)

Network

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:

1. 1. Create a new application (Type HTTP Custom)

1. 1. Set application server IP/FQDN and use Port 443 or 8443 (to check with the responsible of the NAM Server)

1. 1. Set Internal Host (name) to the strict exact name of the NAM Server published hostname. (ex: login.mycompany.com)

1. 1. "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.

1. 1. You can use self-signed certificate

1. 1. In Authentication Tab: DISABLE authentication. As NAM IDP is the authentication service there is no prior authentication to add.

1. 1. In Services Tab: Enable "Access Control" and click on configure rules

1. 1. 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).

1. 1. In advanced settings tab: leave everything by default except for Health Check Configuration.

1. 1. Set "type": HTTPS and "Location": /nidp/app/heartbeat

1. 1. Click on "Show Additional Attributes"

1. 1. 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.

1. 1. Go to deployment and deploy the NAM IDP Application.

Configure SAML 2.0 Federation between NAM and EAA

Prerequisite:

• • A NAM IDP server up and running

Step 1: Configure the EAA Login SP

Preparation:

• • Using your web browser or a CLI tool like curl, download the xml metadata of the NAM IDP Server
    
    
    • • 
        

        https://<nam-idp-fqdn>/nidp/saml2/metadata

    
    
    

In your EAA Management Console:

1. 1. Create a new Identity Providers (EAA Login SP - Type SAML)

1. 1. You can use a Akamai domain

1. 1. 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.

1. 1. 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.

1. 1. Do not tick "Signed SAML Request" for now, the activation of this settings will be explained later.

1. 1. Upload IDP Metadata File - Choose the metadata.xml file you download in the preparation step from the NAM IDP Server.

1. 1. 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:

1. 1. On the NAM Administration Console Dashboard, click on "Applications" in the left panel.

1. 1. Then click on " " and "import Application from file". Select the EAA Connector for NAM zip file attached to this document (EAA Connector for NAM).

1. 1. 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)
      
      

1. 1. 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, ...

1. 1. Click "Save" to finish

1. 1. On the top menu of the admin console, click on "devices" -> "Identity Server"

1. 1. 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):

1. 1. On the landing dashboard page, click on the IDP Cluster link

1. 1. Click on the "SAML2" tab and create a new Service Provider Configuration.

1. 1. Settings:
      
      
      • • 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)
      
      
      

1. 1. Click "Next"

1. 1. Signing Certificate Display should be empty as we did not yet setup one. (will do later)

1. 1. Click "Finish" and then click on the newly created SP on the list

1. 1. Go to "Attributes" tab and on the "Attribute set" select box, select <New Attribute Set>

1. 1. Type a name like "EAA User Profile" and click next

1. 1. 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"
      
      

1. 1. (optional) Do it again for the LDAP attribute "memberOf" (or "groupMembership" for NetIQ eDirectory) and map it or remote attribute "Group"

1. 1. To finish the attribute settings, be sure to select and move all of them to the left column.

1. 1. 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", ...)
      
      
      

1. 1. Click "OK" to Save and exit the configuration

1. 1. Click "OK" again, the list of IDP server is displayed, "deploy" the configuration by clicking "Update All".

Remark:

• • 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:

1. 1. Edit the EAA Login SP (Identity Providers) in EAA Management Console

1. 1. Tick "Sign SAML Request" and copy the public key of the certificate to a local file you can name "nam-eaa-sp-sign.pem"

1. 1. Save & Exit

Configuration in NAM:

1. 1. First task is to upload the public key of the Certificate Authority used by EAA Signing Certificates. In NAM Console go to "Security" -> "Certificates"

1. 1. Copy/Paste the following public key (EAA Signing CA)
      

      -----BEGIN CERTIFICATE-----
      MIIEMzCCAxugAwIBAgIQZYE9cARyEeeCGfRcicFe7zANBgkqhkiG9w0BAQsFADBi
      MQ0wCwYDVQQDDARTb2hhMRswGQYDVQQKDBJTb2hhIFN5c3RlbXMsIEluYy4xEjAQ
      BgNVBAcMCVN1bm55dmFsZTETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMC
      VVMwHhcNMTcwMzA5MDI0NTAzWhcNMzcwMzA0MDI0NTAzWjBiMQ0wCwYDVQQDDART
      b2hhMRswGQYDVQQKDBJTb2hhIFN5c3RlbXMsIEluYy4xEjAQBgNVBAcMCVN1bm55
      dmFsZTETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMwggEiMA0GCSqG
      SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwt674nE05LDtg7gwhmnaMfE rZm06gMji
      BFp9XLVoKm35qaYWUoEMCwo4wJHjuG8Myrv2Mi3PRZi vaE5L5y4yxR 1bnZaNgw
      ZprcqkukxI phSl6kLXJVZ J4GpzXyqHiMa Eh/KWde60W1Vcv7c18KTjVqG3Plx
      KxcAukxOfkuWnacsEOQnCuJ/UZM6mQXI5Y/zfmWEslyyVar9TSxZ50WANpZtaZej
      F9s9n6oMrfOwcG3ZMaCZlMDY5/0yS9F3YKzeAP VViBMXXgGcpqc9tK T5QBaZ8t
      kVcbrqnYm RbADyhog8f0K BFqFfHaiXjD0F7TL rQ5ndo9RSTWjAgMBAAGjgeQw
      geEwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE
      FJRbyeOqMpMRLMEnmlGZt4EVr2qaMIGbBgNVHSMEgZMwgZCAFJRbyeOqMpMRLMEn
      mlGZt4EVr2qaoWakZDBiMQ0wCwYDVQQDDARTb2hhMRswGQYDVQQKDBJTb2hhIFN5
      c3RlbXMsIEluYy4xEjAQBgNVBAcMCVN1bm55dmFsZTETMBEGA1UECAwKQ2FsaWZv
      cm5pYTELMAkGA1UEBhMCVVOCEGWBPXAEchHnghn0XInBXu8wDQYJKoZIhvcNAQEL
      BQADggEBAKywxH3Oca9uGVUIIgYlmOVLUZMdxOdJKjy ve3Mkoo4nhoGoCfuuh7 
      vrhuupxCODyg6 dDFidUI/dBsuhKLxA28aJuN9vpccil89mKtsMmJp5laZ5y2Mrk
      sIsMA8t7a3 snuMY2Puwr3c5LpEwh PRNldVfQRmrSme vG6 rtFadXNSOxE5se1
      NeLVMn66v5cVICvFTboBTRexunA2qObrk8jKhOO1Lp124g72a/12/FnE4Mph 2fr
      Py1P58O7UxMYGqYeDkDsocx9B Yogi/hPhXCfDNkrZG4fvknOtEMIgDJILgFFPeq
      WS3jcl4V8C4TGUfX0zHrOZqitlWs9BU=
      -----END CERTIFICATE-----

1. 1. Then go to "trusted roots" -> "Import..." -> "Certificate data text" and paste the public key.

1. 1. Click OK to Save.

1. 1. Then go the IDP Settings by clicking on the IDP Cluster

1. 1. Go to the "SAML2" tab and click on the EAA Login SP (you previously created) link.

1. 1. 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"

1. 1. 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:

1. 1. Edit a "Application"

1. 1. Go to "Authentication Tab" and assign the EAA Login SP (NAM Identity Providers) you created earlier

1. 1. 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).

Prerequisite:

• • User's group are sent by NAM IDP

To do so, go in EAA Management Console:

1. 1. Edit a "Application"

1. 1. Go to "Services" tab and enable "Access Control"

1. 1. Click on "Configure Rules"

1. 1. 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)

1. 1. 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)

Links

• • 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