Summary

Following these steps will help you configure your Cisco ASA firewall VPN to send SAML auth requests to your Shibboleth servers to authenticate your users. Our preferred way to limit VPN access to groups was to do LDAP searches against our AD, but this might now work for you environment.

Any config changes to the ASA should supplement any existing configurations that you have and not always replace.

Know limitations:

• External browser support is bad for Linux. I am not sure if there is a granular way to allow option that feature, so if its on you might break Linux users.

• OpenConnect doesn't work with SAML, there are some python wrappers but its not for the casual user.

• AnyConnect on Linux breaks a lot, from OS updates. Based on my anecdotal experiences.

• Even with External browser support enabled, you might not get true SSO. If you IP changes when you connect to the VPN and your next SSO auth is with the new IP. Your session is probably attached you “real” IP and will probably need to reauthenticate.

• SAML proxy is not working for us in internal browser.

• If you were using Duo MFA on the web portal before and used there instructions to do so, then you should reverse it. (https://duo.com/docs/ciscoasa-ldap#modify-the-sign-in-page )

Config changes for the ASA

1. Generate the cert to be used by the ASA as the SP. Don’t use the web certs. It should be self signed so that its long lived.

   crypto key generate rsa label SpSigningKeymodulus 2048 crypto ca trustpoint spSigningCert keypair SpSigningKey subject-name cn=*FQDN* enrollment self exit crypto ca enroll spSigningCert

2. Install you Shibboleth IdP certs. You only need your signing cert, if the encryption is different.

   crypto ca trustpoint SAML-IDP-SHIB revocation-check none no id-usage enrollment terminal no ca-check crypto ca authenticate SAML-IDP-SHIB (paste cert) quit exit

3. If you are also setting up LDAP, add your LDAPS cert chain if applicable. Use chain instead of cert if possible to allow for easier renewals.

   crypto ca trustpoint AD-LDAPS revocation-check none no id-usage enrollment terminal no ca-check crypto ca authenticate AD-LDAPS (paste cert) quit exit

4. Setup the WebVPN. The base-url needs to match the host that Shibboleth redirects back to.

5. Depending on what your need is, you might want to map users to specific polices or limit access. I used AD groups for this, and created an LDAP attribute map to bring map the groups. The ASA will take the nameID and do a ldap lookup on it.

6. We duplicated our existing group polices on the ASA because we needed to add the session timeout and wanted to leave the old config intact.

7. For testing, create a new tunnel group to use. After you can confirm that everything is working you can go back and move the SAML auth to the default tunnel group. The metadata is linked to the tunnel group, so you will need to also make changes in the Shibboleth config.

In this example the group-url is the testing site. This hides the SAML login from end users until you are ready to migrate everyone. You can login with the AnyConnect client with the URL or use a browser.

Shibboleth Config changes

1. Edit the metadata-providers.xml file, if the Shibboleth server can talk to your ASA you can use a FileBacked Provider.

   Each tunnel group will have its own entity ID.

2. Allow the release of the attribute that is assigned to the “urn:oasis:names:tc:SAML:2.0:nameid-format:persistent” type.

3. A bean needs to be added to your relying party config file to set the nameID correctly and disable encryption.