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. (Duo Two-Factor Authentication with LDAPS for Cisco ASA SSL VPN with Browser and Secure Client )

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.

   webvpn saml idp YOUR_SP_ENTITY_ID url sign-in <https://SHIB.SITE.URL/idp/profile/SAML2/Redirect/SSO> base-url <https://*fqdnOfTheAssa.com*/> trustpoint idp SAML-IDP-SHIB trustpoint sp spSigningCert signature rsa-sha256 no force re-authentication timeout assertion 300

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.

   !create attriute map ldap attribute-map LDAP-AD-ATTRIB-MAP map-name memberOf Group-Policy map-value memberOf GROUP_DN ASA_GROUPCN VPN_Users_SAML !example !map-value memberOf CN=vpnUsers,OU=SecGroups,DC=uni,DC=edu VPN_Users_SAML !create LDAP server group, add a dc. Add as many as you can. My example users ldaps, remove if your not aaa-server AD-LDAP protocol ldap aaa-server AD-LDAP protocol ldap aaa-server AD-LDAP (asaInterfaceName) host *ip/fqdn of dc* server-port 636 ldap-base-dn ou=users,dc=uni,dc=edu ldap-scope subtree ldap-naming-attribute sAMAccountName ldap-login-password ***** ldap-login-dn CN=asaServiceUser,OU=service,DC=uni,DC=edu ldap-over-ssl enable ldap-attribute-map LDAP-AD-ATTRIB-MAP server-type microsoft

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.

   group-policy VPN_Users_SAML internal from VPN_Users group-policy VPN_Users_SAML attributes vpn-session-timeout 10080

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.

   <!-- saml ASA/VPN service test The text after /metadata is the name of the tunnel group that you setup. If you created a test tunnel group, use this. --> <MetadataProvider id="nameyourASA_test" xsi:type="FileBackedHTTPMetadataProvider" backingFile="%{idp.home}/metadata/filebacked-asa-vpn1_test.xml" metadataURL="<https://asafqdn/saml/sp/metadata/SAML-IdP-SHIB>">
   <!-- saml ASA/VPN service prod The text after /metadata is the name of the tunnel group that you setup. When you setup the production enviroment and use the default tunnel group, use this. --> <MetadataProvider id="nameyourASA_prod" xsi:type="FileBackedHTTPMetadataProvider" backingFile="%{idp.home}/metadata/filebacked-asa-vpn1_prod.xml" metadataURL="<https://asafqdn/saml/sp/metadata/DefaultWEBVPNGroup>">

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.

   <!-- config for the ASA VPN --> <bean parent="RelyingPartyByName"> <constructor-arg name="relyingPartyIds"> <list> <value><https://asafqdn/saml/sp/metadata/SAML-IdP-SHIB</value>> <value><https://asafqdn/saml/sp/metadata/DefaultWEBVPNGroup</value>> </list> </constructor-arg> <property name="profileConfigurations"> <list> <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" p:encryptAssertions="false" p:encryptAttributes="false" p:encryptNameIDs="false" /> </list> </property> </bean>