cancel
Showing results for 
Search instead for 
Did you mean: 
Steve_Lyons
F5 Employee
F5 Employee

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.

Version history
Last update:
‎01-Aug-2018 04:00
Updated by:
Contributors