With step-up authentication, you can authenticate a user at any time during a session.
Step-up authentication can be used to protect layers or parts of a web application that manage more sensitive data. It can be used to increase protection by requiring stronger authentication within an already authenticated access to the web application. Step-up authentication can be a part of using the portal access or web application management (reverse proxy) features of Access Policy Manager® (APM®).
Starts when a subroutine runs and continues until reaching its maximum lifetime (a subroutine setting), or until the session terminates. Does not count against license limits. Populates subsession variables that persist throughout the subsession. Supports logging. Multiple subsessions can exist at the same time, up to a limit of 128 per access session. (When the 129th session is created, the first subsession is removed.)
|1||User logs in and authenticates through an access policy (per-session policy); Access Policy Manager® (APM®) creates a session. User
starts to use an application that's available in the enterprise. User can access all but two
parts of the application that APM protects with step-up authentication, which requires:
|2||User requests access to part of the application protected with step-up authentication (username and password). APM challenges the user and then starts a subsession; for simplicity, we call it Subsession 1. For the duration of Subsession 1: If the user passed step-up authentication, the user does not need to authenticate again to access that part of the application; If the user failed step-up authentication, the user does not have access and step-up authentication does not run again.|
|3||User requests access to part of the application protected with step-up authentication
certificate authentication. APM challenges the user and then starts another subsession,
Subsession 2. If the user passes certificate authentication, for the duration of Subsession
2: If the user passed step-up authentication, the user does not need to authenticate again to
access that part of the application; If the user failed step-up authentication, the user does
not have access and step-up authentication does not run again.
Tip: A subsession ends when its lifetime expires or when the session ends, whichever is sooner.
Access Policy Manager® (APM®) supports these authentication types for step-up authentication:
One way to identify an application or some part of an application that you want to protect is by using the URL Branching agent in a per-request policy to specify a URI and branch on it.
In this example, the URL Branching agent matches substrings that indicate requests to sensitive areas of a web application named siterequest. Matching requests are protected with Active Directory or multi-factor step-up authentication.
This example subroutine authenticates a user with Active Directory.
The user gets three authentication retries because the Maximum Macro Loop Count is set to 3. Because the Gating Criteria is blank, the subroutine can create only one distinct subsession. While the subsession exists, if the user makes another request that matches the application area, the user is not challenged again for authentication.
This example subroutine uses RADIUS to authenticate a user. This configuration supports multi-factor authentication when it is implemented using third-party products that integrate through RADIUS.
Using the Variable Assign agent (renamed as Store Client IP in this example), it's possible to save the client IP address, then compare it to the original client IP address from the start of the session and, if it changes, run LDAP authentication.
In this example, the Variable Assign agent stores a value in a pre-defined custom variable.
In the illustration, Predefined Variables is selected, Group is set to Per-Request Variables, and Variable is set to Scratchpad. An iRule in the Custom Expression field gets the value, which is the client IP address.
In this example, perflow.scratchpad is specified as the Gating Criteria in the subroutine settings. In another example, you can see the per-request policy store the client IP address in the predefined Scratchpad variable. The Scratchpad variable (available through the Variable Assign agent), equates to the perflow.scratchpad variable that is available in subroutine settings.
In this example, a change in the client IP address (stored in the gating criteria, perflow.scratchpad) triggers the step-up authentication subroutine to run. However, we want the user to authenticate using LDAP only if the client IP address is not the same one that started the session. An agent in the subroutine, Source IP Check (configured from the Empty agent), makes this comparison.
These are the configuration objects and settings you need to create when you implement step-up authentication.
These steps guide you through configuring a per-request policy for step-up authentication.
|AD Auth||Add after a Logon Page agent.|
|CRLDP Auth||To validate a certificate, add after On-Demand Cert Auth.|
|HTTP Auth||Add after a Logon Page agent.|
|LDAP Auth||Add after a Logon Page agent.|
|LocalDB Auth||Add after a Logon Page agent.|
|OAuth Client||Add after a OAuth Logon Page agent.|
|OAuth Scope||Add after a OAuth Logon Page agent.|
|On-Demand Cert Auth||In the agent properties, be sure the set Auth Mode to Require.|
|OCSP Auth||To validate a certificate, add after On-Demand Cert Auth.|
|RADIUS Auth||Add after a Logon Page agent.|
|perflow.custom or perflow.scratchpad||Custom value that you must populate with Variable Assign|
|perflow.category_lookup.result.hostname||This value is automatically populated.|
|perflow.category_lookup.result.url||This value is automatically populated.|
||URL data, available with an SWG subscription, that you must populate with Category Lookup|
|perflow.category_lookup.result.customcategories||URL data, available with or without an SWG subscription, that you must populate with Category Lookup|
|perflow.resource_assign_pool.name||Pool name that you must populate with Pool Assign|
|perflow.protocol_lookup.result||Protocol type (HTTP or HTTPS) that you must populate with Protocol Lookup|
|perflow.ssl_bypass.set||Defaults to False; can be set to True with SSL Bypass Set (or set to False with SSL Intercept Set)|
|A perflow variable with application_lookup in its name||Application name or family that you must populate with Application Lookup|
|perflow.session.id||This value is automatically populated and does not change. When this variable is selected, step-up authentication will run once.|
|perflow.username||This value is automatically populated. Username won't usually change but might change.|
Session variables might not change throughout a session. However, in conjunction with other data, they can be used to create distinctive subsessions that control which resources a user can reach. A Variable Assign agent or an iRule agent could put a string into the perflow.custom or perflow.scratchpad variable like this example:
An administrator can derive the example string from a session variable and date-time information.
The F5 DevCentral online community is the source for information about iRules®. BIG-IP® Access Policy Manager®: Visual Policy Editor on the AskF5™ web site located at support.f5.com provides information about session variables, perflow variables, and Tcl usage, all of which can be helpful when working with Variable Assign.