A customer recently reached out requesting assistance providing smart card authentication to an application that does not integrate with AD or LDAP and has only a single username and password. While many of you out there may have done this in the past, I for one had not and of course I too was curious how I could make such a solution work. So with that, let's get to it.
In order to successfully deploy this solution, please configure the following prerequisites.
- Local Traffic Manager licensed and provisioned
- Access Policy Manager licensed and provisioned
- CA certificate or a bundle of CA certs
Note: This CA cert or bundle will contain all CA certs which issued the client certificates you will be authenticating with.
- OCSP IP address for certificate revocation checking
Configuring a LDAP AAA Resource
- Navigate to Access > Authentication > LDAP and select Create
- Name: Demo_LDAP_AAA
- Server Connection: Direct
- Base Port: 389
- Admin DN: CN=admin,CN=Users,DC=demo,DC=lab
- Leave all other settings at their defaults and select Finished
Configuring a OCSP AAA Resource
- Navigate to Access > Authentication > OCSP Responder > Select Create
- Name: Demo_OCSP
- URL: http://OCSP_IP/ocsp
- Certificate Authority File: Select the issuing CA Certificate
- Leave all other settings at their defaults and select Finished
Creating a Webtop
- Navigate to Access >> Webtops >> Webtop Lists: Create
- From the drop down select Full for the type of Webtop you will be deploying, provide a name and select Finished.
Identify Form, Form Action and Form Parameters
In this scenario I used Firefox though your favorite browser can also be used. This data will be used to configure our SSO profile.
- Lunch Firefox and browse to the application you are attempting to configure SSO for.
- From the Firefox Menu bar, select Tools >> Web Developer >> Click Inspector
To make it easy to identify the form I simply clicked in the USERNAME or PASSWORD in fields in the web page and Inspector took me to that content.
- Capture action: /console/j_spring_security_check
- Capture method: POST
- Capture input id for the username parameter
- Capture input id for the password parameter
Create a Forms SSO Profile
- Navigate to Access >> Single Sign-On >> Forms Based >> Click Create
- Name: Demo_Web_App_Forms_SSO
- User SSO Template: None
- Username Source: session.sso.token.last.username
- Password Source: session.sso.token.last.password
- Start URI: This is URI of the application at the logon screen
- Form Method: Post
- Form Action: /console/j_spring_security_check
- Form Parameter For User Name: username
- Form Parameter For Password: password
- Click Finished
Create a Portal Access Resource
- Navigate to Access >> Connectivity / VPN >> Portal Access >> Portal Access List >> Click Create
- Name: Demo_Web_App
- Link Type: Application URI
- Application URI: URI to your web application
- Caption: Demo_Web_App
- Click Create
After you click Create, the page will refresh and at the bottom of the screen you will then see an option to create Resource Items
- Click Add
- Destination: IP or Host Name of the web application
- Link Type: Paths
- Paths: /*
- Scheme: https
- SSO Configuration: Demo_Web_App_Forms_SSO
- Click Finished
Create a Connectivity Profile
- Navigate to Access >> Connectivity / VPN > Connectivity >> Profiles >> Click Add
- Profile Name: Demo_CP
- Parent Profile: connectivity
- Click OK
Create Client Cert Access Policy
- Navigate to Access > Profiles / Policies > Select Create
- Name: Demo_cert_Auth
- Profile Type: All
- Profile Scope: Profile
- Languages: Select your desired language and move it to Accepted Languages
- Leave all other settings at their defaults and select Finished
Modify the Access Policy Using the Visual Policy Editor
- From the Access > Profiles > Policies : Access Profiles (Per-Session Policies) page, select Edit from the access policy created in the previous step.
- Between Start and Deny select the +
- From the popup select the Authentication tab and select On_Demand Cert Auth > Add Item
- You will be presented with an option to request or require a client present a client certificate. For this example, we will Require the client present a certificate.
- Select Save
- Following the successful branch of On Demand Cert Auth in the VPE, select +
- From the Authentication tab, select OCSP Auth > Add Item
- From the OCSP Responder drop down, select the OCSP AAA object created in previous steps.
- Certificate Type: User
- Click Save
- Following the successful branch of OCSP Auth, select +
- From the Assignment tab, select Variable Assign > Add Item
- From the first empty Assignment, select Change
- Custom Variable: session.sso.token.last.password
- Select Secure from the drop down menu
Note: Unsecure or Secure specifies whether the variable is secure. A secure variable is stored in encrypted form in the session database. The value of a secure variable is not displayed in the session report, or logged by the logging agent.
- Text: password
- Select Finished
- Under Variable Assign, select Add new entry > Change empty variable
- Custom Variable: session.sso.token.last.username
- Text: admin
- Under Variable Assign, select Add new entry > Change empty variable
- Custom Variable: session.logon.last.upn
- Custom Expression:
set x509e_fields [split [mcget {session.ssl.cert.x509extension}] "\n"]; # For each element in the list: foreach field $x509e_fields { # If the element contains UPN:
if { $field contains "othername:UPN" } { ## set start of UPN variable set start [expr {[string first "<" $field] +1}] # UPN format is # Return the UPN, by finding the index of opening and closing brackets, then use string range to get everything between. return [string range $field $start [expr { [string first ">" $field $start] - 1 } ] ]; } } # Otherwise return UPN Not Found: return "UPN-NOT-FOUND";
- Select Finished > Save
- Select Save
- Following the fallback branch of Variable Assign, select +
- From the Authentication tab, select LDAP Query > Add Item
- From the Server drop down, select the LDAP AAA created in previous steps
- SearchDN: CN=Users,DC=demo,DC=lab
- SearchFilter: UserPrincipalName=%{session.logon.last.upn}
- Fetch Groups to which the user or group below: Direct
- Required Attributes: sAMAccountName
- Required Attributes: memberOf
Note: sAMAccountName is not required for successful authentication as it is when performing Kerberos KCD though it can be useful to know who is logging in by name versus a long string of characters.
- Navigate to the Branch Rules tab
- Remove the existing Group Membership expression by selecting the X
- Select Add Branch Rule
- Name: LDAP Query Successful
- Next to expression, select change
- Agent Sel: LDAP Query
- Condition: LDAP Query Passed
- LDAP Query has: Passed
- Select Add Expression > Finished
- Click Save
- Following the LDAP Query Successful branch, select +
- From the Assignment tab, select SSO Credential Mapping > Add Item
- SSO Token Username: mcget {session.sso.token.last.username}
- SSO Token Password: mcget {session.sso.token.last.password}
- Click Save
- Following the SSO Credential Mapping branch select +
- Select Advanced Resource Assign from the Assignment tab
- Click Add new entry
- Click Add/Delete
- From the Portal Access tab, select the Demo_Web_App resource created in previous tasks.
- From the Webtop tab, select the demo_webtop created in previous tasks.
- Click Update
- Click Save
- From the fallback branch, select Deny
- Change ending to Allow and click Save
At this point, you have a fully deployed VPE capable of supporting smart card authentication and have statically created a username and password that will be included in your HTTP Post to the web application.
- Select Apply Policy
Configure SSL Client Profile
- To support client certificate-based authentication, we must also create a Client SSL Profile on the BIG-IP using the steps below.
- Navigate to Local Traffic > Profiles > SSL > Client > Create
- Name: DemoSSLProfile
- Certificate Key Chain: Place a check mark under the custom field. Click Add to select the appropriate cert/key pair.
- Client Certificate: Leave it set to ignore as the APM ODCA will perform this function.
- Trusted Certificate Authorities: Select the CA or CA bundle certificate
- Advertised Certificate Authorities: Select the CA or CA bundle certificate
- All other settings can be left at their defaults.
- Click Finished
Create a Virtual Server for your Web Application
- Navigate to Local Traffic >> Virtual Servers >> Click Create
- Name: Demo_Web_App_VS
- Destination Address: IP that users will connect to in order to access the web application
- Service Port: 443
- Protocol Profile (Client): f5-tcp-lan
- HTTP Profile: http
- SSL Profile (Client): DemoSSLProfile
- SSL Profile (Server): serverssl
- Source Address Translation: Automap
- Rewrite Profile: rewrite_portal
- Access Profile: Demo_cert_Auth
- Connectivity Profile: Demo_CP
- Click Finished
At this point, we have successfully configured all components required to support this use case so let's attempt access.
Validation Testing
- From a browser navigate to the IP of your virtual server or the DNS name that resolves that IP
- You should be prompted for user certificate
- Select your user cert and Click OK
- You should be presented with your Webtop
- Click on the resource item and you should be redirected to that web application
- If your configuration is correct, you will be logged in using the SSO credentials provided within the VPE and SSO profile.
In my first attempt I actually was not successful and received no logon error. This is likely one of 2 things, either I did not assign my SSO profile or the Start URI is incorrect. Let's validate
- Validated SSO profile is assigned
Ahhh, now I see! Human error of course. I typed the Start URI incorrectly so, no there was no uri match.
After modifying the Start URI to the correct URI, I am now able to successfully login using the SSO configuration in this guide.
I am by no means saying this will be a common configuration though it is a use case that I have seen in the field more than once. As always, if it helps at least one of you out there it was well worth it. Until next time.