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

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.

Summary

  1. Requirements
  2. Architecture
  3. EAA (SP) Configuration
  4. NAM (IDP) Configuration
  5. Optional: Using Signed SAML Request
  6. Test & Troubleshooting
  7. Chain of Access Control
  8. Links

Requirements

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

    arch-nam-noeaa-nosso

  • 2/ Publishing NAM IDP with the help of EAA. (Using EAA Cloud DMZ)

    arch-nam-eaa-nosso

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. 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.
  2. 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)
  3. 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).
  4. 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.
  5. 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. Create a new application (Type HTTP Custom)
  2. Set application server IP/FQDN and use Port 443 or 8443 (to check with the responsible of the NAM Server)
  3. Set Internal Host (name) to the strict exact name of the NAM Server published hostname. (ex: login.mycompany.com)
  4. 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.

    eaa01

  5. You can use self-signed certificate
  6. In Authentication Tab: DISABLE authentication. As NAM IDP is the authentication service there is no prior authentication to add.
  7. In Services Tab: Enable “Access Control” and click on configure rules
  8. 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).

    eaa02

  9. In advanced settings tab: leave everything by default except for Health Check Configuration.
  10. Set “type“: HTTPS and “Location”: /nidp/app/heartbeat

    eaa03

  11. Click on “Show Additional Attributes
  12. 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.

    eaa04

  13. 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. Create a new Identity Providers (EAA Login SP – Type SAML)
  2. You can use a Akamai domain
  3. 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.
  4. 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.
  5. Do not tick “Signed SAML Request” for now, the activation of this settings will be explained later.
  6. Upload IDP Metadata File – Choose the metadata.xml file you download in the preparation step from the NAM IDP Server.
  7. 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. On the NAM Administration Console Dashboard, click on “Applications” in the left panel.

    eaa14

  2. Then click on “+” and “import Application from file”. Select the EAA Connector for NAM zip file attached to this document (EAA Connector for NAM).
  3. 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)

    eaa15

  4. 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, …

    eaa16

  5. Click “Save” to finish
  6. On the top menu of the admin console, click on “devices” -> “Identity Server”

    eaa17

  7. Click on “Update All” to deploy the new configuration.

    eaa18

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. On the landing dashboard page, click on the IDP Cluster link

    eaa05

  2. Click on the “SAML2” tab and create a new Service Provider Configuration.

    eaa06

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

      eaa07

  4. Click “Next
  5. Signing Certificate Display should be empty as we did not yet setup one. (will do later)
  6. Click “Finish” and then click on the newly created SP on the list
  7. Go to “Attributes” tab and on the “Attribute set” select box, select <New Attribute Set>

    eaa08

  8. Type a name like “EAA User Profile” and click next
  9. 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

    eaa09

  10. (optional) Do it again for the LDAP attribute “memberOf” (or “groupMembership” for NetIQ eDirectory) and map it or remote attribute “Group
  11. To finish the attribute settings, be sure to select and move all of them to the left column.

    eaa10

  12. 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“, …)

      eaa11

  13. Click “OK” to Save and exit the configuration
  14. Click “OK” again, the list of IDP server is displayed, “deploy” the configuration by clicking “Update All“.

    eaa12

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

    eaa13

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. Edit the EAA Login SP (Identity Providers) in EAA Management Console
  2. Tick “Sign SAML Request” and copy the public key of the certificate to a local file you can name “nam-eaa-sp-sign.pem”

    eaa19

  3. Save & Exit

Configuration in NAM:

  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

    Screenshot at oct. 11 18-03-31

  2. 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-----
  3. Then go to “trusted roots” -> “Import…” -> “Certificate data text” and paste the public key.

    Screenshot at oct. 11 18-06-03

  4. Click OK to Save.
  5. Then go the IDP Settings by clicking on the IDP Cluster

    eaa20

  6. Go to the “SAML2” tab and click on the EAA Login SP (you previously created) link.

    eaa21

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

    eaa22

  8. 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. Edit a “Application
  2. Go to “Authentication Tab” and assign the EAA Login SP (NAM Identity Providers) you created earlier
  3. 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. Edit a “Application
  2. Go to “Services” tab and enable “Access Control
  3. Click on “Configure Rules
  4. 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)

    eaa23

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

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading...

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

No Comments
By: civ75
Oct 20, 2017
2:19 pm
Reads:
393
Score:
Unrated
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow