apm sso form-basedv2ΒΆ

apm sso form-basedv2(1)       BIG-IP TMSH Manual       apm sso form-basedv2(1)



NAME
       form-basedv2 - Configures a single sign-on form-basedv2 configuration
       object.

MODULE
       apm sso

SYNTAX
       Configure the form-basedv2 component within the sso module using the
       syntax shown in the following sections.

   CREATE/MODIFY
	create form-basedv2 [name]
	  options:
	    app-service [[string] | none]
	    forms [add | replace-all-with] {
	      [name] {
		request-value [URIs]
		controls [add | replace-all-with] {
		  [name] {
		    value [string]
		  }
		}
	      }
	    }

	modify form-basedv2 [name]
	  options:
	    apm-log-config [[string] | none]
	    app-service [[string] | none]
	    forms [add | delete | modify | replace-all-with] {
	      [name] {
		options:
		  app-service [[string] | none]
		  attribute-value [[string] | none]
		  controls [add | delete | modify | replace-all-with] {
		    [name] {
		      options:
			app-service [[string] | none]
			secure [true | false]
			value [string]
		    }
		  }
		  description [[string] | none]
		  form-order [integer]
		  id-type [action | id | inputs | name | order]
		  request-method [get | post]
		  request-name [[string] | none]
		  request-negative [true | false]
		  request-prefix [true | false]
		  request-type [cookie | header | uri]
		  request-value [[string] | none]
		  submit-autodetect [true | false]
		  submit-javascript [[string] | none]
		  submit-javascript-type [auto | custom | extra]
		  submit-method post
		  submit-name [[string] | none]
		  submit-negative [true | false]
		  submit-prefix [true | false]
		  submit-type [cookie | header | uri]
		  submit-value [[string] | none]
		  success-match-type [cookie | none | url]
		  success-match-value [[string] | none]
	      }
	    }
	    headers [add | delete | modify | none | replace-all-with] {
	      [name] {
		options:
		  app-service [[string] | none]
		  description [[string] | none]
		  name [string]
		  value [string]
	      }
	    }
	    log-level [alert | crit | debug | emerg | err | info | notice | warn]

	edit form-basedv2 [ [ [name] | [glob] | [regex] ] ... ]
	  options:
	    all-properties
	    non-default-properties

	reset-stats
	reset-stats [ [ [name] | [glob] | [regex] ] ... ]

   DISPLAY
	list form-basedv2
	list form-basedv2 [ [ [name] | [glob] | [regex] ] ... ]
	show running-config form-basedv2
	show running-config form-basedv2 [ [ [name] | [glob] |
				    [regex] ] ... ]
	  options:
	    all-properties
	    non-default-properties
	    one-line
	    partition

	show form-basedv2
	show form-basedv2 [name]

   DELETE
	delete form-basedv2 [name]

DESCRIPTION
       You can use the form-basedv2 component to configure an SSO form-basedv2
       configuration object. When creating a new SSO form-based v2
       configuration object, you must add at least one forms item and within
       it at least one controls item. You must also provide a value for the
       request-value option in the forms item.

       The SSOv2 module identifies and processes two types of application HTTP
       requests - logon page requests and credentials submit requests. Logon
       page requests are identified using the request- set of options.
       Credentials submit requests, in most cases, are identified
       automatically. When this fails, you can set the submit-autodetect
       option to false and use the submit- set of options to identify these
       requests.

       When the SSOv2 module identifies a logon page request, it scans the
       response trying to find the logon form. If the logon form is found,
       SSOv2 inserts a JavaScript code that will cause the logon form to be
       submitted automatically by the browser. The client must support
       JavaScript.

       When the SSOv2 module identifies a credentials submit request, it
       compares POST data parameter names with form controls defined in the
       configuration. For a POST data parameter name that has a corresponding
       form control, the SSOv2 module replaces its value with the control
       value from the configuration. Control values are usually supplied
       through session variables, such as session.sso.token.last.username and
       session.sso.token.last.password. POST data parameters that have no
       corresponding controls in the configuration are not changed.

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

       Every forms item must include at least one controls item, and can
       include up to 32 controls items. Each controls item represents an input
       element of an HTML logon form, such as form fields for entering
       username and password, and, optionally, any hidden form parameters. The
       name of the controls item must match the name attribute of the
       corresponding input tag of the form. For example, if the form has the
       following HTML tag for entering the username:

	   

       the forms item must include a controls item with the name
       Bugzilla_login. The controls item used for entering the user's password
       must have the secure option set to true. The value of a control item
       should usually be the name of a session variable, starting with the
       percent (%) sign and enclosed in curly braces ({}); for example, the
       value for the username control item:
       %{session.sso.token.last.username}. The value can also be a string, or
       a combination of strings and session variable names.

EXAMPLES
       create form-basedv2 fbssov2-owa2010 { forms add { owa2010 { controls
       add { password { secure true value %\{session.sso.token.last.password\}
       } username { value  %\{session.sso.token.last.username\} } } request-
       value /owa/auth/logon.aspx\?replaceCurrent=1 submit-javascript clkLgn()
       submit-javascript-type extra success-match-type cookie success-match-
       value sessionid } } }

       Creates an SSO form-basedv2 configuration object named fbssov2-owa2010.

       delete fbsso-owa2010

       Deletes an SSO form-basedv2 configuration object named fbssov2-owa2010.

OPTIONS
       app-service
	    Specifies the name of the application service to which the object
	    belongs. The default value is none. Note: If the strict-updates
	    option is enabled on the application service that owns the object,
	    you cannot modify or delete the object. Only the application
	    service can modify or delete the object.

       forms
	    Specifies one or more items, each defining SSO processing of a
	    separate application logon form.

       [name]
	    Specifies the name of the form item. It does not have to match the
	    actual name of the HTML form and can be arbitrary.

	    The options are:

	    app-service
		 Specifies the name of the application service to which the
		 form item belongs. The default value is none. Note: If the
		 strict-updates option is enabled on the application service
		 that owns the object, you cannot modify or delete the form
		 item. Only the application service can modify or delete the
		 form item.

	    attribute-value
		 Specifies the value of the HTML 
tag attribute used to identify the logon form. The attribute could be id, name, or action, and is specified by the id-type option. For other values of the id-type option, this is not used and should be set to none. controls Specifies one or more form control items (up to 32) that you want to be processed by SSOv2. [name] Specifies the name of the HTML form control item. It must match the name attribute value of the HTML form's input tag. The options are: app-service Specifies the name of the application service to which the control item belongs. The default value is none. Note: If the strict-updates option is enabled on the application service that owns the object, you cannot modify or delete the control item. Only the application service can modify or delete the control item. secure Specifies whether the control item represents the HTML input tag of type "password". The default is false. value Specifies the value of the control item. This is usually the name of a session variable. If the session variable is not found when the SSO request is processed, the value of the corresponding POST parameter will be empty. The value could also be a literal string or a combination of strings and session variable names. description User-defined description. form-order Specifies the order of the HTML logon form on the logon page when the id-type option is set to order. Starts with 1. id-type 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 matching the criteria, the first match is used. The default is inputs. The options are: action The logon form is identified by the value of the tag in the action attribute. The value is specified in the attribute-value option. id The logon form is identified by the id attribute's value of the tag. The value is specified in the attribute-value option. name The logon form is identified by the name attribute's value of the tag. The value is specified in the attribute-value option. order The logon form is identified by its relative order on the logon page (starting from 1). The order is specified in the form-order option. inputs The logon form is identified by a combination of controls items. The controls in the configuration must have corresponding elements in the form. request-method Specifies the HTTP method of the application's request returning logon page. Default is get. request-name Specifies the name of the HTTP cookie or the name of the HTTP header used to identify application's request for logon page. The cookie or header is selected by the request-type option. The value of the cookie or header is specified by the request-value option. When the request-type option is set to uri, this option is not used and should be set to none. request-negative When set to true, the application's request for logon page will be identified by the absence of the specified cookie or header, or by a failed match against the list of specified URIs. The default is false. request-prefix Specifies how the value of the request-value option will be used to match one of the HTTP request cookie, header, or URI. The default is true and specifies a partial match; false specifies an exact match. request-type Specifies which element of the HTTP request headers is used to identify the application's request for logon page. The default is uri. The options are: cookie The request is identified by the presence (or absence) of a cookie. The name and value of the cookie are specified by the request-name and request-value options. header The request is identified by the presence (or absence) of the HTTP header. The name and value of the header are specified by the request-name and request-value options. uri The request is identified by a successful (or failed) match against a list of URIs specified by the request-value option, and the request-name option is not used. request-value Specifies the value of the HTTP request element that must be matched to identify the request as the application's request for the logon page. This is one of: the cookie value, the header value, or a list of URIs (one per line) as specified by the request-type option. Cookie or header value could be set to none, in which case only the presence of the named cookie or header is checked and the value is not checked. When checking for URI, the value must be specified. submit-autodetect When set to true, the application's HTTP request that submits the user's credentials will be identified automatically and other submit- options should not be used. When false, the form submit will be identified using a combination of other submit- options. The default is true. submit-javascript Specifies user-provided JavaScript code to be inserted into the logon page to perform automatic form submission when the submit- javascript-type option is set to custom. The custom JavaScript code replaces the code automatically generated by the SSOv2 module. When the submit-javascript-type option is set to extra, it specifies the application's JavaScript functions to call from the automatically generated JavaScript code prior to submitting a logon form. When the submit-javascript-type option is set to auto, this option should be set to none. submit-javascript-type Specifies the type of JavaScript code to be inserted into the logon page by the SSOv2 module to perform automatic logon form submission. The options are: auto JavaScript code is automatically generated by the SSOv2 module. custom JavaScript code is provided by the user in the submit- javascript option. extra JavaScript code is automatically generated by the SSOv2 module, and additional JavaScript code provided by the user in the submit-javascript option is inserted before the form submit statement. submit-method Specifies the HTTP method of credentials submit request for the application. This must be set to post. This option is not used when submit-autodetect is true. submit-name Specifies the name of the HTTP cookie or the name of HTTP header used to identify credentials submit request for the application. The cookie or header is selected by the submit-type option. The value of the cookie or header is specified by the submit-value option. When the submit-type option is set to uri, this option is not used and should be set to none. This option is not used when submit-autodetect is true. submit-negative When set to true, the credentials submit request for the application is identified by the absence of a specified cookie or header, or by a failed match against the list of specified URIs. The default is false. This option is not used when submit- autodetect is true. submit-prefix Specifies how the value of the submit-value option will be used to match the HTTP request cookie, header, or URI. The default is true and specifies partial match; false specifies exact match. This option is not used when submit-autodetect is true. submit-type Specifies which element of HTTP request headers is used to identify the credentials submit request for the application. The default is uri. This option is not used when submit-autodetect is true. The options are: cookie The request is identified by the presence (or absence) of a cookie. The name and value of the cookie are specified by the submit-name and submit-value options. header The request is identified by the presence (or absence) of the HTTP header. The name and value of the header are specified by the submit-name and submit-value options. uri The request is identified by a successful (or failed) match against a list of URIs specified by the submit-value option and the submit-name option is not used. submit-value Specifies the value of the HTTP request element that must be matched to identify the request as a credentials submit request for the application. This is one of: the cookie value, the header value, or a list of URIs (one per line) as specified by the submit-type option. Cookie or header value could be set to none, in which case only the presence of the named cookie or header is checked and the value is not checked. When checking for URI, the value must be specified. This option is not used when submit- autodetect is true. success-match-type Specifies how the SSOv2 module detects whether the credentials submit request was successful. When the SSOv2 module detects that the credentials submission failed, the SSOv2 configuration used for this HTTP transaction is disabled for the user session. If you specify a value for this option, you must also specify a value for success-match-value. The default is none. The options are: url Credentials submission was successful if the response contains the HTTP Location header with a value matching one of the URLs specified by the success-match-value option. cookie Credentials submission was successful if the response contains the HTTP cookie with the name specified by the success-match-value option. none No check is performed. If SSO logon fails and the application server redirects back to the logon page that matches the criteria of the logon page request, SSO will be retried, possibly causing authentication loop. success-match-value Specifies the value used to detect the success or failure of the SSO logon. When the success-match-type option is set to url, this is a list of URLs. Each URL in the list can contain a single wildcard character (*). When the success-match-type option is set to cookie, this option specifies the name of the cookie. The default is none. headers Specifies the name and value of the HTTP header to be inserted in an HTTP Request that passes through the APM SSOv2 module. [name] Specifies the name of the headers item. The options are: app-service Specifies the name of the application service to which the HTTP header belongs. The default value is none. Note: If the strict-updates option is enabled on the application service that owns the object, you cannot modify or delete the HTTP header. Only the application service can modify or delete the HTTP header. name Specifies the name of the HTTP header. value Specifies the value of the HTTP header. apm-log-config Specifies log-setting object to associate with this sso. If this value is empty, logging framework uses log-setting configuration associated with the access profile where sso is used. log-level log-level is deprecated. Instead use apm-log-config to customize log-setting. SEE ALSO basic, kerberos, ntlmv1, ntlmv2, form-based COPYRIGHT No part of this program may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or information storage and retrieval systems, for any purpose other than the purchaser's personal use, without the express written permission of F5 Networks, Inc. F5 Networks and BIG-IP (c) Copyright 2012-2013, 2016. All rights reserved. BIG-IP 2016-09-28 apm sso form-basedv2(1)