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.