BIG-IP Access Policy Manager Single Sign-On Configuration Guide. Version 11.2

(1)

Sign-On Configuration Guide

(2)

(3)

Chapter 1: Configuring Single Sign-On with Access Policy Manager...9

What is Single Sign-On?...10

Chapter 2: Single Sign-On Methods...11

What are the supported SSO methods?...12

About the Single Sign-On configuration object...12

Configuring SSO using HTTP Basic authentication method...12

General SSO object attributes...13

Configuring SSO using HTTP forms authentication method...13

HTTP Forms SSO object attributes...14

Configuring SSO using NTLM v1 authentication method...15

Configuring SSO using NTLM v2 authentication method...15

Chapter 3: Form-based Client-initiated Single Sign-On Method...17

Why use form-based client-initiated SSO authentication?...18

Basic configuration of form-based client-initiated SSO ...18

How does form-based client-initiated SSO authentication work by default? ...18

About advanced configuration options for form-based client-initiated SSO authentication....20

Configuring SSO using form-based client-initiated authentication method...20

Forms-based client-initiated object attributes...21

Form-based client-initiated SSO configuration examples...24

DWA form-based client-initiated SSO example...24

DWA form-based client-initiated SSO screen-by-screen example ...25

Bugzilla form-based client-initiated SSO example...33

Ceridian form-based client-initiated SSO example...34

Citrix 4.5 and 5 form-based client-initiated SSO example...36

Devcentral form-based client-initiated SSO example...37

Google form-based client-initiated SSO example...39

Oracle Application Server form-based client-initiated SSO example...40

OWA 2010 and 2007 form-based client-initiated SSO example...40

OWA 2003 form-based client-initiated SSO example...41

Perforce form-based client-initiated SSO example...42

Reviewboard form-based client-initiated SSO example...43

SAP form-based client-initiated SSO example...44

(4)

Sharepoint 2010 form-based client-initiated SSO example...46

Weblogin form-based client-initiated SSO example...47

Yahoo form-based client-initiated SSO example...48

Chapter 4: Kerberos Single Sign-On Method...51

About Kerberos SSO...52

How does Kerberos SSO work in Access Policy Manager?...52

Task summary for configuring Kerberos SSO...53

Setting up a delegation account to support Kerberos SSO...53

Configuring SSO with Kerberos authentication method...54

Editing an access policy to support Kerberos SSO...54

Binding a Kerberos SSO object to an access profile...55

Attaching an access profile to a virtual server for Kerberos SSO...55

Kerberos SSO session variable list...55

Tips for successfully deploying Kerberos SSO...56

Chapter 5: Single Sign-On and Multi-Domain Support...59

About multi-domain support for SSO...60

How does multi-domain support work for SSO?...60

Task summary for configuring domain support for SSO...62

Configuring an access policy for SSO single domain support...62

Configuring an access policy for SSO multi-domain support...63

Creating a virtual server for SSO multi-domain support...63

Chapter 6: Common Deployment Examples for Single Sign-On...65

Common use cases for Single Sign-On deployment...66

Task summary for configuring web application over network access tunnel for SSO...66

Configuring network access for SSO with web applications...66

Configuring network access properties...67

Configuring and managing the access profile using SSO...67

Configuring an HTTP virtual server for the network access...67

Configuring a layered virtual server for your web service...68

(5)

Publication Date

This document was published on May 7, 2012. Publication Number

MAN-0363-02 Copyright

F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice.

Trademarks

3DNS, Access Policy Manager, Acopia, Acopia Networks, Advanced Client Authentication, Advanced Routing, APM, Application Security Manager, ARX, AskF5, ASM, BIG-IP, Cloud Extender, CloudFucious, CMP, Data Manager, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client, Edge Gateway, Edge Portal, EM, Enterprise Manager, F5, F5 [DESIGN], F5 Management Pack, F5 Networks, F5 World, Fast Application Proxy, Fast Cache, FirePass, Global Traffic Manager, GTM, IBR, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iApps, iControl, iHealth, iQuery, iRules, iRules OnDemand, iSession, IT agility. Your way., L7 Rate Shaping, LC, Link Controller, Local Traffic Manager, LTM, Message Security Module, MSM, Netcelera, OneConnect, Packet Velocity, Protocol Security Module, PSM, Real Traffic Policy Builder, ScaleN, SSL Acceleration, StrongBox, SuperVIP, SYN Check, TCP Express, TDR, TMOS, Traffic Management Operating System, TrafficShield, Transparent Data Reduction, VIPRION, vCMP, WA, WAN Optimization Manager, WANJet, WebAccelerator, WOM, and ZoneRunner, are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without F5's express written consent.

All other product and company names herein may be trademarks of their respective owners. Patents

This product may be protected by U.S. Patent 7,114,180. This list is believed to be current as of May 7, 2012.

Export Regulation Notice

This product may include cryptographic software. Under the Export Administration Act, the United States government may consider it a criminal offense to export this product from the United States.

RF Interference Warning

This is a Class A product. In a domestic environment this product may cause radio interference, in which case the user may be required to take adequate measures.

(6)

FCC Compliance

This equipment has been tested and found to comply with the limits for a Class A digital device pursuant to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This unit generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user, at his own expense, will be required to take whatever measures may be required to correct the interference.

Any modifications to this device, unless expressly approved by the manufacturer, can void the user's authority to operate this equipment under part 15 of the FCC rules.

Canadian Regulatory Compliance

This Class A digital apparatus complies with Canadian ICES-003. Standards Compliance

This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to Information Technology products at the time of manufacture.

(7)

This product includes software developed by Bill Paul. This product includes software developed by Jonathan Stone. This product includes software developed by Manuel Bouyer. This product includes software developed by Paul Richards.

This product includes software developed by the NetBSD Foundation, Inc. and its contributors. This product includes software developed by the Politecnico di Torino, and its contributors.

This product includes software developed by the Swedish Institute of Computer Science and its contributors. This product includes software developed by the University of California, Berkeley and its contributors. This product includes software developed by the Computer Systems Engineering Group at the Lawrence Berkeley Laboratory.

This product includes software developed by Christopher G. Demetriou for the NetBSD Project. This product includes software developed by Adam Glass.

This product includes software developed by Christian E. Hopps. This product includes software developed by Dean Huxley. This product includes software developed by John Kohl. This product includes software developed by Paul Kranenburg. This product includes software developed by Terrence R. Lambert. This product includes software developed by Philip A. Nelson. This product includes software developed by Herb Peyerl.

This product includes software developed by Jochen Pohl for the NetBSD Project. This product includes software developed by Chris Provenzano.

This product includes software developed by Theo de Raadt. This product includes software developed by David Muir Sharnoff. This product includes software developed by SigmaSoft, Th. Lockert.

This product includes software developed for the NetBSD Project by Jason R. Thorpe.

This product includes software developed by Jason R. Thorpe for And Communications, http://www.and.com. This product includes software developed for the NetBSD Project by Frank Van der Linden.

This product includes software developed for the NetBSD Project by John M. Vinopal. This product includes software developed by Christos Zoulas.

This product includes software developed by the University of Vermont and State Agricultural College and Garrett A. Wollman.

This product includes software developed by Balazs Scheidler ([email protected]), which is protected under the GNU Public License.

(8)

This product includes software developed by Niels Mueller ([email protected]), which is protected under the GNU Public License.

In the following statement, This software refers to the Mitsumi CD-ROM driver: This software was developed by Holger Veit and Brian Moore for use with 386BSD and similar operating systems. Similar operating systems includes mainly non-profit oriented systems for research and education, including but not restricted to NetBSD, FreeBSD, Mach (by CMU).

This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/).

This product includes software licensed from Richard H. Porter under the GNU Library General Public License (©_{1998, Red Hat Software), www.gnu.org/copyleft/lgpl.html.}

This product includes the standard version of Perl software licensed under the Perl Artistic License (©_1997, 1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current standard version of Perl at http://www.perl.com.

This product includes software developed by Jared Minch.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).

This product includes cryptographic software written by Eric Young ([email protected]).

This product contains software based on oprofile, which is protected under the GNU Public License. This product includes RRDtool software developed by Tobi Oetiker (http://www.rrdtool.com/index.html) and licensed under the GNU General Public License.

This product contains software licensed from Dr. Brian Gladman under the GNU General Public License (GPL).

This product includes software developed by the Apache Software Foundation (http://www.apache.org/). This product includes Hypersonic SQL.

This product contains software developed by the Regents of the University of California, Sun Microsystems, Inc., Scriptics Corporation, and others.

This product includes software developed by the Internet Software Consortium.

This product includes software developed by Nominum, Inc. (http://www.nominum.com).

This product contains software developed by Broadcom Corporation, which is protected under the GNU Public License.

This product contains software developed by MaxMind LLC, and is protected under the GNU Lesser General Public License, as published by the Free Software Foundation.

(9)

1

Configuring Single Sign-On with Access Policy Manager

Topics:

(10)

What is Single Sign-On?

Access Policy Manager®

provides a Single Sign-On (SSO) feature that leverages the credential caching and credential proxying technology.

Credential caching and proxying is a two-phase security approach that allows your users to enter their credentials once to access their secured web applications. By leveraging this technology, users request access to the secured back-end web server. After that occurs, Access Policy Manager creates a user session and collects the user identity based on the access policy. When the access policy successfully is complete, the user identity is saved (cached) in a session database. Access Policy Manager subsequently reuses the cached identity to seamlessly log the user into the secured web applications, thus providing the user with a single sign on experience.

The Single Sign-On (SSO) feature provides the following benefits: • Eliminates the need to administer and maintain multiple user logons • Eliminates the need for users to enter their credentials multiple times.

(11)

2

Single Sign-On Methods

Topics:

(12)

What are the supported SSO methods?

Access Policy Manager®

supports the following SSO authentication methods. Description

SSO method

Access Policy Manager uses the cached user identity and sends the request with the authorization header. This header contains the token Basic and the

base64-encoded for the user name, colon, and the password. HTTP Basic Auth

Upon detection of the start URL match, Access Policy Manager uses the cached user identity to construct and send the HTTP form-based post request on behalf of the user.

HTTP Forms

Upon detection of the request for logon page (URI, header, or cookie that is configured for matching the request), Access Policy Manager generates HTTP Forms - Client

Initiated

JavaScript code, inserts it into the logon page and returns the logon page to the client, where it is automatically submitted by inserted JavaScript. APM processes the submission and uses the cached user identity to construct and send the HTTP form-based post request on behalf of the user.

NTLM employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to the server. HTTP NTLM Auth v1

NTLM employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to the server. This version of NTLM is an updated version from NTLM v1.

HTTP NTLM Auth v2

This provides transparent authentication of users to Windows Web application servers (IIS) joined to Active Directory domain. It is used when IIS servers Kerberos

request Kerberos authentication; this SSO mechanism allows the user to get a Kerberos ticket and have Access Policy Manager present it transparently to the IIS application.

About the Single Sign-On configuration object

Access Policy Manager supports various SSO methods. Each method contains a number of attributes that you need to configure properly to support SSO.

Mis-configuring SSO objects for any of these authentication methods (HTTP Basic, NTLM v1 and v2, and Kerberos) could disable SSO for all authentication methods for a user's session when the user accesses a resource with the mis-configured object. The exceptions are Forms and Forms - Client Initiated, which are the only SSO methods that are not disabled when any other method fails due to a mis-configured SSO object.

(13)

The SSO Configuration List screen opens.

2. From the menu bar, select SSO Configurations by Type and select an SSO type from the list. A screen appears, displaying SSO configurations of that type.

3. Click Create.

The New SSO Configuration screen opens. 4. Type a name for the SSO object.

5. In the Credentials Source area, specify the user name and password you want cached for Single Sign-On. 6. Click Finished.

General SSO object attributes

Of these general attributes, the Username source attribute applies to all SSO methods. Session variable defaults Description

Name of attribute

N/A Defines the authentication method for your SSO configuration object. You can select from the SSO method

following choices: HTTP Basic, Form Based, NTLMV1, NTLMV2, or Kerberos.

session.sso.token.last.username

Defines the source session variable name of the user name for SSO authentication.

Username Source

session.sso.token.last.password

Defines the source session variable name of the password for SSO authentication.

Password Source

session.sso.domain.source

Converts pre-Windows 2000/UPN username input format to the format you want to use for Username

Conversion

SSO. For example, convert domain\username

or username@domain to username.

Configuring SSO using HTTP forms authentication method

With the HTTP forms method of authentication, upon detection of the start URL match, the SSO plug-in uses the cached user identity to construct and send the HTTP form-based POST request on behalf of the user.

1. On the Main tab, expand Access Policy, and click SSO Configurations. The SSO Configuration List screen opens.

2. From the menu bar, click SSO Configurations By Type and select Forms from the list. A list of Form Based Configurations is displayed.

The New SSO Configuration screen opens. 4. Type a name for the SSO object.

5. From the Use SSO Template list, select the template you want to use.

The screen refreshes to show additional settings applicable to the specific template.

6. In the SSO Method Configuration area, specify all relevant parameters. Refer to the online help for specific information on each parameter.

(14)

HTTP Forms SSO object attributes

The following object attributes apply specifically to the HTTP Forms SSO method.

Session Variable Supported Description Name of Attribute start_uri

Defines the start URI value. HTTP form-based authentication executes for SSO if the HTTP request URI matches the start Start URI

URI value. You can specify multiple start URI values in multiple lines for this attribute. s

If you check this box, cookies presented in the form will be propagated to the client browser.

Pass Through

Defines the method of the HTTP form-based authentication for SSO. The options are GET or POST. By default, the Form Method

form method value is set to POST. However, if you specify GET, the SSO authentication method becomes an HTTP GET request.

form_action

Defines the form action URL used for HTTP authentication request for SSO. For example,

Form Action

/access/oblix/apps/webgate/bin/webgate.dll. If you do not specify a value for this attribute, the original request URL is used for SSO authentication.

form_parameter

Defines the parameter name of the login user name. For example, the user ID is specified as the attribute value if the HTTP server expects the user name in the form of userid=. Form Parameter

For User Name

Defines the name of the login password. For example, Pass

is specified as the attribute value if the HTTP server expects the password in the form of pass=.

Form Parameter for Password

Defines the hidden form parameters required by the authentication server login form at your location. You must Hidden Form

Parameters/Values

enter hidden parameters, like this: param1 value1 param2 value2. Separate each parameter's name and value by a space, and not by an equal sign. Each parameter must start on a new line.

success_match_value

Defines how Access Policy Manager detects whether the user was successfully authenticated by the server. You can select one:

Successful Logon Detection Match Type

• By Resulting Redirect URL: Specifies that the authentication success condition is determined by examination of the redirect URL from the HTTP response. You can specify multiple values for this option. • By Presence Of Specific Cookie: Specifies that the

authentication success condition is determined by the presence of the named cookie in the response. Cookie

(15)

Session Variable Supported Description

Name of Attribute

Defines the value used by the specific success detection type; that is, the redirect URL or cookie name.

Successful Logon Detection Match Value

Configuring SSO using NTLM v1 authentication method

With this method of authentication, NTLM employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to a server.

The New SSO Configuration screen opens. 3. From the SSO method list, select NTLM v1.

5. Click Finished.

Configuring SSO using NTLM v2 authentication method

With this method of authentication, NTLM employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to a server. This version of NTLM has been updated from version 1.

The New SSO Configuration screen opens. 3. From the SSO method, select NTLMV2.

(16)

(17)

3

Form-based Client-initiated Single Sign-On Method

Topics:

• Why use form-based client-initiated SSO authentication?

• Basic configuration of form-based client-initiated SSO

• How does form-based client-initiated SSO authentication work by default?

• About advanced configuration options for form-based client-initiated SSO

authentication

• Configuring SSO using form-based client-initiated authentication method

• Forms-based client-initiated object attributes

• Form-based client-initiated SSO configuration examples

(18)

Why use form-based client-initiated SSO authentication?

You can use the Form-based Client-initiated SSO method to create forms-based SSO configurations that are suitable for many use cases. For example, you can use this SSO method to support web applications that run JavaScript in the browser and need to maintain application state during the logon process and for web applications that present multiple logon screens.

Basic configuration of form-based client-initiated SSO

To create a form-based client-initiated SSO configuration object, you must configure at least one form and include at least one form parameter. A form parameter represents an input element on an HTML logon form, such as a form field for entering username or password, or, optionally, for entering a hidden form parameter.

Form-based client-initiated SSO configuration supports three sets of matching criteria for you to define using the following menu items.

• Form Detection (Mandatory) - Configure the SSO module to detect the HTTP request for the logon page by matching the HTTP URI, header, or cookie that you specify. You must enter data that is specific to the application. Entry of multiple URIs is supported. Form detection is successful when the request matches one of the configured items either partially or fully, depending on whether Request Prefix is enabled in the Advanced Properties section.

• Form Identification (Optional) - Specify how to detect the form within the HTTP body of the logon page. The default setting is Form Parameters; this setting enables identification of the login form parameter fields based on the values entered for the form parameters in the General Properties dialog. Alternatively, you can specify that the form be identified using other data present in the form, such as the ID, name, or action attributes, or the form order. Defaults to Form Parameters.

• Successful Logon Detection (Optional) - Configure the SSO module to detect whether logon was successful by checking for the presence of a cookie or a redirect URI. Defaults to None (logon detection is not performed).

The majority of web applications have a single logon page with one logon form. You need to define a single form for these applications. In less usual cases when an application has multiple logon pages with different logon forms, you will need to create multiple forms, one for each logon page. If multiple logon pages use the same form, you will need only one form with a list of URIs for all logon pages.

How does form-based client-initiated SSO authentication work by default?

The following figure illustrates the default behavior of the form-based client-initiated SSO authentication method.

(19)

Figure 1: Form-based client-initiated SSO default behavior

1. The user logs on to Access Policy Manager®

and APM executes the access policy. This populates the session variables with the user credentials.

2. The user requests the application logon page. This GET request is passed to the application web server verbatim.

3. The application web server replies with 200 OK and serves the logon page.

4. APM generates JavaScript and inserts it into the logon page before returning it to the user. The JavaScript assigns values to form parameters, as specified in the form configuration. The password parameter is assigned a password token rather than the actual user password.

5. The JavaScript runs on the client side. The logon page is not displayed to the user; user input is locked out. Without delay, the form is submitted using POST. The form parameters and their values, including username and password token, are sent to APM.

6. APM then replaces the password token with the actual user password, as well as other form parameters specified in the form configuration with their configured values.

7. The POST, along with the real user credentials from step 1, is sent to the web server.

8. The application start page is served by the webserver, and sent to the client verbatim. Optionally, APM performs detection of successful logon by examining HTTP response headers, looking for a cookie or redirect Location URI.

(20)

About advanced configuration options for form-based client-initiated SSO

authentication

You can change some aspects of the Form-based Client-initiated SSO default behavior by configuring optional properties.

• Advanced Properties - Enables you to change the default properties for form request and form submittal. • JavaScript Insertion - Enables you to change the automatically generated JavaScript code that gets

inserted into the logon page in one of these ways. Replace it completely with custom code or add extra code to it by specifying the application JavaScript functions to call prior to submitting a logon form. • Form Submit Detection - Enables the SSO module to automatically detect the application HTTP request

that submits user credentials; if automatic detection is disabled, the SSO module instead detects form submittal by using an HTTP header, cookie, or HTTP URIs that you specify. Defaults to enabled (automatic).

Configuring SSO using form-based client-initiated authentication method

With the HTTP form-based client-initiated method of authentication, when Access Policy Manager® detects the request for logon page (URI, header, or cookie that is configured for matching the request), APM generates JavaScript code, inserts it into the logon page,and returns logon page to the client, where it is automatically submitted by the inserted JavaScript. The APM processes the submission and uses the cached user identity to construct and send the HTTP form-based post request on behalf of the user.

2. From the menu bar, select SSO Configurations by Type and select an SSO type from the list. A screen appears, displaying SSO configurations of that type.

3. Click Create over the Available Forms-Client Initiated Configurations table. A New Forms-Client Initiated window pops up.

4. Type a name for the SSO object.

5. Click Create over the Forms in this SSO Configuration table. You must create at least one form to complete the SSO configuration. The New Form Definition window appears.

6. Type a name in the Form Name field and click Create above the Forms Parameters table. The New Form Parameter window appears.

7. Select a Parameter Type, fill in a name and a value for the parameter and click OK.

You are returned to the New Form Definition window where the new form parameter is displayed. 8. Click OK.

The new SSO configuration appears in the Available Forms-Client Initiated Configurations table and the new form appears in the Forms for Forms-Client Initiated SSO Config table.

(21)

Forms-based client-initiated object attributes

The following tables list the attributes that compose an SSO forms-based client-initiated configuration. SSO configuration properties

Table 1: SSO configuration properties

Value Field

Specifies the name of the configuration. It must be unique. SSO Configuration Name

Specifies a description. Optional. SSO Description

Valid values are listed. Defaults to Notice. Log Level

Form Definition

Table 2: General Properties

Value Field

Specifies the name of the form. It can be any name; it does not need to match the actual name of the HTML form.

Form Name

Specifies a description. Optional. Form Description

Table 3: Form Parameter Properties

Value Field

Specifies whether the parameter represents username, password, or a custom parameter.

Parameter Type

Specifies the parameter name for the user name. Defaults to username. Username Parameter Name

Note: This parameter name must match the parameter name

for the user name that used in the logon page; to determine the correct name, view the logon page source.

Specifies the value of the username. Defaults to a session variable. (For information about setting a value, see Form Parameter Value.) Username Parameter Value

Specifies the parameter name for the password. Defaults to password. Password Parameter Name

Specifies the value of the password. Defaults to a session variable. (For information about setting a value, see Form Parameter Value.) Password Parameter Value

Specifies whether or not the parameter is a password. Defaults to checked for Password parameter type; otherwise defaults to unchecked. Secure

Specifies the name of a custom parameter. Form Parameter Name

(22)

Value Field

Specifies the value of the custom parameter. This is usually the name of a session variable. The value could also be a literal string or a combination of strings and session variable names.

Form Parameter Value

Note: If the session variable is not found when the SSO request

is processed, the value of the corresponding POST parameter will be empty.

Table 4: Form Detection

Value Field

Specifies which element of the HTTP request headers is used to identify the application request for logon page :Cookie, Header, or URI. Defaults to URI.

Detect Form by

Specifies a cookie name. The form is identified by the presence (default) or absence (configurable with Advanced Properties) of this cookie.

Cookie

Specifies a header name and value. The form is identified by the presence (default) or absence (configurable with Advanced Properties) of this header.

Header

Specifies one or more URIs (one per line). The form is identified by a successful match (default) or failed (configurable with Advanced Properties) against this list of URIs.

URI

Table 5: Form Identification

Value Field

Specifies how the HTML logon form is found in the HTML body of the logon page. If there is more than one form on the logon page Identify Form by

matching the criteria, the first match is used. Values are ID Attribute, Name Attribute, Action Attribute, Form Order, Form Parameters. Defaults to Form Parameters.

Specifies that the form parameters, which have already been defined, are used to find the form. There is nothing more to configure. Form Parameters

Specifies the form ID that is used to identify the form. Form ID

Specifies the value of the form name. Form Name

Specifies the value of the action attribute. Form Action

Specifies the relative order of the form on the logon page (starting from 1).

(23)

Table 6: Successful Logon Detection

Value Field

Specifies whether and how to detect a successful logon. Values are Presence of Cookie, Redirect URI, and None. Defaults to None, in which case no determination is made.

Detect Logon by

Specifies the cookie name that identifies successful logon. Cookie Name

Specifies the redirect URI that identifies successful logon. Redirect URI

Table 7: Advanced Properties - Form Request

Value Field

Specifies whether the request method is GET or POST. Defaults to GET.

Request Method

When selected, specifies that the form be detected by failing to match the criteria specified for Form Detection. The form is then detected by Request Negative

the absence of the specific cookie or header or by the failure to match the URIs. Defaults to unchecked.

This configuration option allows you to match on a partial string. If not selected, the match must be verbatim. Defaults to selected. Request Prefix

Table 8: Advanced Properties - Submit Request

Value Field

Specifies whether the request method is GET or POST. Defaults to POST.

Request Method

When selected, specifies that the form be detected by failing to match the criteria specified for Form Detection. The form is then detected by Submit Request Negative

the absence of the specific cookie or header or by the failure to match the URIs. Defaults to unchecked.

This configuration option allows you to match on a partial string. If not selected, the match must be verbatim. Defaults to selected. Submit Request Prefix

Table 9: JavaScript Injection

Value Field

Specifies whether to use the default JavaScript that APM creates. Defaults to Auto.

Injection Method

Specifies more JavaScript to run at the end of the automatically generated JavaScript.

Extra Javascript

Note: Check the logon page source to determine whether any

JavaScript functions are called on submit.

Specifies JavaScript to run in place of the automatically generated JavaScript.

(24)

Table 10: Form Submit Detection

Value Field

Defaults to not selected. Disable Auto detect submit

Form-based client-initiated SSO configuration examples

Examples are provided for various applications so that you can quickly create form-based client-initiated SSO configurations for them.

DWA form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Domino Web Access (DWA).

Table 11: DWA Configuration Example

Navigation Notes Sample Value

User Interface Field

SSOv2 Properties

ssov2-dwa

SSO Configuration Name

SSOv2 Properties > Create > New Form Definition Forms in this SSO

Configuration table

New Form Definition: General Properties

testform

Form Name

General Properties > Create > New Form Parameter Form Parameters table

New Form Parameter •

• Parameter Type Username

• Username Parameter • Name Username • %{session.sso.token.last.username} • Username Parameter Value

• Not enabled (Default) • Secure

• Parameter Type Password

• Password Parameter • Name Password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure

(25)

Form Identification

STLogonForm

Form Name

Successful Logon Detection

Presence of Cookie

Detect Logon by

DomAuthSessId

Cookie Name

Advanced Properties Not selected

Request Prefix

DWA form-based client-initiated SSO screen-by-screen example

This example shows how to create a form-based client-initiated SSO configuration for Domino Web Access (DWA) by providing a screen-by-screen illustration.

DWA Form-based Client Initiated SSO Configuration Screens

Figure 2: SSOv2 Properties

1. You must type a name for the SSO configuration. 2. Start creating a form.

(26)

Figure 3: New Form Definition - General Properties

1. You must type a name for the form.

(27)

Figure 4: Form Parameter Properties - Username

For the Username parameter type, the default parameter name is username. In the above example, the parameter name has been changed to Username. This is done because, for DWA, a parameter name must start with an uppercase letter

(28)

Figure 5: Form Parameter Properties - Password

(29)

Figure 6: Completed General Properties Definition

(30)

Figure 7: Form Detection

(31)

Figure 8: Form Identification

(32)

Figure 9: Successful Logon Detection

(33)

Figure 10: Advanced Properties

The Request Prefix check box (which is checked by default) has been cleared because, for DWA, the form request must match verbatim.

Bugzilla form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Bugzilla. Table 12: Bugzilla Configuration Example

ssov2-bugzilla

Configuration table

New Form Definition: General Properties

tform

Form Name

(34)

• Username Parameter • Name Bugzilla_login • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter • Name Bugzilla_password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection / Request URI Form Identification ID Attribute Identify Form by Form Identification mini_login_top Form ID

Presence of Cookie

Detect Logon by

Bugzilla_logincookie

Cookie Name

Request Prefix

Ceridian form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Ceridian. Settings to configure form-based client-initiated SSO for Ceridian

Table 13: Ceridian Configuration Example

ssov2_ceridian

sourcetimepro1.ceridian.com

Description

Configuration table

General Properties

auth_form

Form Name

General Properties > Create Form Parameters table

(35)

• Form Parameter Value • %{session.logon.last.clientid}

• Secure • Not enabled (Default)

• Username Parameter Name

• SerialNumberInput

• %{session.sso.token.last.username}

• Username Parameter

Value • Not enabled (Default) • Secure

• Password Parameter Name • PasswordInput • %{session.sso.custom.last.password} • Password Parameter Value • Disabled • Secure Form Detection URI Detect Form by Form Detection / Request URI /sta.asp /ctagw/ /ctagw/sta.asp Form Identification Form Parameters Identify Form by

Redirect URI

Detect Logon by

https://sourcetimepro1.ceridian.com/CTA660/cta.asp?RequestID=* Redirect URI Advanced Properties Not selected Request Prefix Javascript Injection Custom Injection Method Javascript Injection See code below.

Custom Javascript

Advanced Properties > Form Submit Detection

Selected Disable Auto detect submit

Form Submit Detection

/sta.asp URI /ctagw/sta.asp Custom JavaScript <script> function checkInternetExplorerVersion()

// Returns 'true' if the version of Internet Explorer > 8 {

(36)

if (navigator.appName == 'Microsoft Internet Explorer') {

var ua = navigator.userAgent;

var re = new RegExp("MSIE ([0-8]{1,}[\.0-9]{0,})"); if (re.exec(ua) != null)

r = parseFloat( RegExp.$1 ); }

return ( r==-1 ) ? true : false; } if (checkInternetExplorerVersion()) { document.body.style.visibility='hidden'; document.body.style.display='none'; } document.body.onkeydown=function(e){return false;}; function __f5submit() {

var __f5form = document.forms[0];

__f5form.SerialNumberInput.value='%{session.sso.token.last.username}'; __f5form.PasswordInput.value='%{session.sso.custom.last.password}'; __f5form.ClientIDInput.value='%{session.logon.last.clientid}'; f_submit(); } if (window.addEventListener) { window.addEventListener('load',__f5submit,false); } else if (window.attachEvent) { window.attachEvent('onload',__f5submit); } else { window.onload=__f5submit; } </script>

Logon Page customization in access policy

Logon Page Agent (field 3): • Type:text

• Post Variable Name:clientid

• Session Variable Name:clientid

Logon Page Input Field #3:Company ID

Variable Assign definition in access policy

session.sso.custom.last.password = expr { [mcget -secure {session.sso.token.last.password}] }

Citrix 4.5 and 5 form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Citrix®

4.5 and 5. Table 14: Citrix 4.5 and 5 Configuration Example

SSOv2 Properties SSO Configuration Name

(37)

• Parameter Type Custom

• Form Parameter Name • domain

•

• Form Parameter Value %{session.logon.last.domain}

• Username Parameter • Name user • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter • Name password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection /Citrix/AccessPlatform/auth/login.aspx Request URI /Citrix/XenApp/auth/login.aspx Form Identification Action ID Identify Form by Form Identification login.aspx Form Action

Redirect URI

Detect Logon by

*/Citrix/XenApp/site/default.aspx

Redirect URI

*/Citrix/AccessPlatform/site/default.aspx

Devcentral form-based client-initiated SSO example

(38)

Settings to configure form-based client-initiated SSO for Devcentral Table 15: Devcentral Configuration Example

ssov2_devcentral

devcentral.f5.com

Description

Configuration table

auth_form

Form Name

• Form Parameter Name • dnn$ctr1093548$Login$Login_DNN$cmdLogin

• Form Parameter Value • Login

• dnn$ctr1093548$Login$Login_DNN$txtUsername

• Password Parameter Name • dnn$ctr1093548$Login$Login_DNN$txtPassword • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection /Community/Login/tabid/1082224/Default.aspx Request URI /tabid/1082224/Default.aspx Form Identification Form Parameters Identify Form by

Cookie

Detect Logon by

authentication

(39)

Extra Javascript

WebForm_DoPostBackWithOptions(new

WebForm_PostBackOptions("dnn$ctr1093548$Login$Login_DNN$cmdLogin", "", true, "", "", false, false));

__f5form.enctype = 'application/x-www-form-urlencoded'; __f5form.encoding = 'application/x-www-form-urlencoded';

Google form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Google. Settings to configure form-based client-initiated SSO for Google

Table 16: Google Configuration Example

ssov2_google

accounts.google.com

Description

Configuration table

form_auth

Form Name

• Email

• Password Parameter Name • Passwd • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection /ServiceLogin Request URI Form Identification Form Parameters Identify Form by

Cookie

Detect Logon by

SID

(40)

Note: For Internet Explorer 7 (and 8), disable the advanced setting "Display a notification about

every script error".

Oracle Application Server form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Oracle®

10g Release 2 (10.1.2).

Table 17: Oracle Application Server 10g Configuration Example

ssov2_oracle

Configuration table

tform

Form Name

• Username Parameter • Name ssousername • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter • Name password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection /sso/pages/login.jsp?site2pstoretoken=v1.2 Request URI Form Identification Form Parameters Identify Form by

Cookie

Detect Logon by

SSO_ID

Cookie Name

(41)

Table 18: OWA 2010 and OWA 2007 Configuration Example

ssov2-owa

Configuration table

tform

Form Name

• Username Parameter • Name username • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter • Name password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection /owa/auth/logon.aspx?replaceCurrent=1&url= Request URI /owa/auth/logon.aspx?url= Form Identification Form Parameters Identify Form by

Presence of Cookie

Detect Logon by

sessionid Cookie Name Javascript Injection Extra Injection Method Javascript Injection clkLgn() Extra Javascript

OWA 2003 form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Outlook Web App (OWA) 2003.

Table 19: OWA 2003 Configuration Example

ssov2-owa2003

(42)

Configuration table

tform2003

Form Name

• Password Parameter • Name password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection /exchweb/bin/auth/owalogon.asp?url=https://ata.bldg12.grpy.company.com/exchange/&reason=0 Request URI Form Identification Form Parameters Identify Form by

Presence of Cookie

Detect Logon by

sessionid

Cookie Name

Perforce form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Perforce. Table 20: Perforce Configuration Example

perforce-sso

Configuration table

p4

Form Name

General Properties > Create Form Parameters table

(43)

User Interface Field • Username Parameter Name • u • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter • Name p • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection /p4web Request URI Form Identification Form Parameters Identify Form by

Presence of Cookie

Detect Logon by

P4W8080

Cookie Name

Request Prefix

Reviewboard form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Reviewboard. Table 21: Reviewboard Configuration Example

reviewboard-sso

Configuration table

rb_logon

Form Name

(44)

User Interface Field • Password Parameter Name • password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by Form Detection /account/login Request URI Form Identification Form Parameters Identify Form by

Redirect URI

Detect Logon by

*/dashboard

Redirect URI

Request Prefix

SAP form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for SAP®

. Table 22: SAP Configuration Example

ssov2_sap

Configuration table

tform

Form Name

• Username Parameter • Name j_user • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter • Name j_password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default)

(45)

• Form Parameter Name • uidPasswordLogon

•

• Form Parameter Value Log On

Form Detection URI Detect Form by Form Detection /irj/portal Request URI Form Identification Form Parameters Identify Form by

Presence of Cookie

Detect Logon by

MYSAPSSOV2

Cookie Name

Request Prefix

Salesforce form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Salesforce. Settings to configure form-based client-initiated SSO for Salesforce

Table 23: Salesforce Configuration Example

ssov2_salesforce

Configuration table

auth_form

Form Name

• Username Parameter Name • username • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter Name • pw • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure Form Detection URI Detect Form by

(46)

Form Detection / Request URI Form Identification Form Parameters Identify Form by

Cookie

Detect Logon by

inst Cookie Name Javascript Injection Custom Injection Method Javascript Injection See code below.

function checkInternetExplorerVersion()

var r = -1; // Return value assumes agreement.

return ( r==-1 ) ? true : false; } if (checkInternetExplorerVersion()) { document.body.style.visibility='hidden'; document.body.style.display='none'; } document.body.onkeydown=function(e){return false;}; function __f5submit() {

var __f5form = document.forms[0];

__f5form.username.value='%{session.sso.token.last.username}'; __f5form.password.value='f5-sso-token';

;

var __f5action = __f5form.action;

(47)

Table 24: Sharepoint Configuration Example

ssov2_shp2010

Configuration table

form_auth

Form Name

• Username Parameter • Name ctl00$PlaceHolderMain$signInControl$UserName • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter • Name ctl00$PlaceHolderMain$signInControl$password • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure

• Form Parameter Name • ctl00$PlaceHolderMain$signInControl$login

•

• Form Parameter Value Sign In

• Secure • Enabled Form Detection URI Detect Form by Form Detection /_forms/default.aspx?ReturnUrl= Request URI Form Identification Form Parameters Identify Form by

Cookie

Detect Logon by

FedAuth

Cookie Name

Weblogin form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for weblogin. Table 25: Weblogin Configuration Example

ssov2-weblogin

(48)

Configuration table

tform

Form Name

• Username Parameter • Name user • %{session.sso.token.last.username} • Username Parameter Value

• Password Parameter • Name pass • %{session.sso.token.last.password} • Password Parameter Value • Enabled (Default) • Secure

• Form Parameter Name • submit_form

•

• Form Parameter Value Submit

Form Detection URI Detect Form by Form Detection /sso/login.php?redir= Request URI Form Identification Name Attribute Identify Form by Form Identification theForm Form Name

Cookie

Detect Logon by

issosession

Cookie Name

Yahoo form-based client-initiated SSO example

This example shows how to create a form-based client-initiated SSO configuration for Yahoo. Settings to configure form-based client-initiated SSO for Yahoo

(49)

login.yahoo.com

Description

Configuration table

form_login

Form Name

• login

Value • Not enabled (Default) • Secure Form Detection URI Detect Form by Form Detection / Request URI Form Identification ID Attribute Identify Form by Form Identification login_form Form ID

Cookie

Detect Logon by

PH Cookie Name Javascript Injection Custom Injection Method Javascript Injection See example custom Javascript below.

Advanced Properties > Form Submit Detection Selected

Disable Auto detect submit

Form Submit Detection

/config/login

Javascript

//Logon page will not be hidden in IE7/8.

//This is workaround for the problem with JS method .focus()

//"Can't move focus to the control because it is invisible, not enabled, or of a type that does not accept the focus."

function checkInternetExplorerVersion()

var r = -1; // Return value assumes agreement.

return ( r==-1 ) ? true : false; }

(50)

document.body.style.visibility='hidden'; var inter = setInterval(function () {

var adv = document.getElementById('adFrame'); if (adv) adv.style.visibility='hidden';

Variable Assign definition used in access policy

session.sso.custom.last.password = expr { [mcget -secure {session.sso.token.last.password}] }

BIG-IP Access Policy Manager Single Sign-On Configuration Guide. Version 11.2

Sign-On Configuration Guide

Table of Contents

Chapter 1: Configuring Single Sign-On with Access Policy Manager...9

Chapter 2: Single Sign-On Methods...11

Chapter 3: Form-based Client-initiated Single Sign-On Method...17

Chapter 4: Kerberos Single Sign-On Method...51

Chapter 5: Single Sign-On and Multi-Domain Support...59

Chapter 6: Common Deployment Examples for Single Sign-On...65

1

Configuring Single Sign-On with Access Policy Manager

What is Single Sign-On?

2

Single Sign-On Methods

What are the supported SSO methods?

About the Single Sign-On configuration object

General SSO object attributes

Configuring SSO using HTTP forms authentication method

HTTP Forms SSO object attributes

Configuring SSO using NTLM v1 authentication method

Configuring SSO using NTLM v2 authentication method

3

Form-based Client-initiated Single Sign-On Method

Why use form-based client-initiated SSO authentication?

Basic configuration of form-based client-initiated SSO

How does form-based client-initiated SSO authentication work by default?

About advanced configuration options for form-based client-initiated SSO

authentication

Configuring SSO using form-based client-initiated authentication method

Forms-based client-initiated object attributes

Form-based client-initiated SSO configuration examples

DWA form-based client-initiated SSO example

DWA form-based client-initiated SSO screen-by-screen example

Bugzilla form-based client-initiated SSO example

Ceridian form-based client-initiated SSO example

Citrix 4.5 and 5 form-based client-initiated SSO example

Devcentral form-based client-initiated SSO example

Google form-based client-initiated SSO example

Oracle Application Server form-based client-initiated SSO example

OWA 2003 form-based client-initiated SSO example

Perforce form-based client-initiated SSO example

Reviewboard form-based client-initiated SSO example

SAP form-based client-initiated SSO example

Salesforce form-based client-initiated SSO example

Weblogin form-based client-initiated SSO example

Yahoo form-based client-initiated SSO example