Idea Transcript
Back | Next | Contents
Cams Administrator's Guide
Login Configuration The Cams authentication services provides a virtual directory where one or more user directories (typically Active Directory, LDAP or an SQL > open and close tags, as shown in the sample login-config.xml file.
NOTE: Cams login pages contain a required cams_login_config hidden field value that is dynamically populated or statically hard coded, which specifies the security domain-specific to use. When dynamically populated, this value is obtained from the cams.loginconfig.entry value defined in cams-webagent.conf for the Cams web agent that populates the login page. The default http value, may be changed, but should be used for most sites. Within the open and close tags, you specify how login modules will be used. The parameters className and flag are required for each as show in Example 1. The class name specifies the fully-qualified Java class used to reference a login module. The Java class names for the standard
login modules supplied with Cams are: com.cafesoft.cams.auth.login.module.ActiveDirectoryLoginModule com.cafesoft.cams.auth.login.module.DigipassJdbcLoginModule com.cafesoft.cams.auth.login.module.JdbcLoginModule com.cafesoft.cams.auth.login.module.LdapLoginModule com.cafesoft.cams.auth.login.module.RsaSecurIdLoginModule com.cafesoft.cams.auth.login.module.UnboundIDLdapLoginModule com.cafesoft.cams.auth.login.module.X509CertificateLdapLoginModule com.cafesoft.cams.auth.login.module.XmlLoginModule NOTE: Additional login modules are supplied in the Cams distribution for use with Cams Automatic Enterprise Sign-on (AESO). A few undocumented login modules are also available. For these, see the login module source code comments, available in the documentation download, for configuration instructions.
Example 1 - Cams login-config.xml example with required parameters in red A can have one or more . Use of more than one is known as stacking. The required flag parameter determines the login module behavioral dependencies, which is especially important when login modules are stacked. The flag can be one of four values: REQUIRED - The login module must be successful for overall authentication to succeed. Any failure results in the return of an error after executing all other login modules on the stack. REQUISITE - The login module must be successful for overall authentication to succeed. Any failure results in the immediate return of an error, no more login modules in the stack are executed. A message reflecting the first failed required or requisite login module is returned. SUFFICIENT - If the login module succeeds, overall authentication succeeds without trying any other login modules in the stack. Failure cases are treated the same as optional. OPTIONAL - A login module failure is ignored and overall authentication success will be a function of other login modules in the stack. The interaction between flags when stacking can be complicated so you should keep these configurations as simple as possible. Most sites specify a single login module with flag value set to REQUIRED. Additional values are specific to each login module and described in the sections below. All tags require name and value parameters. For example, all Cams login modules include a debug option to toggle debug on and off. The tag is with true or false as the value. NOTE: The Jetty test web server that is included with the Cams policy server provides login module configurators to test login module values and generate the associated XML using your browser. Login module configurators are provided for Active Directory, LDAP and SQL flag="REQUIRED">
Example 3 - Cams Active Directory login module login-config.xml sample The Active Directory login module options values are: debug - Enables/disables debugging for the login module. host - The DNS host name or IP address of the Active Directory server. port - The Active Directory server connection port (389 by default, 636 for SSL). Note that the Active Directory login module may also connect to the Global Catalog (port 3268 by default). useSSL - (optional) A flag that enables/disables use of SSL for connections. Use true to enable SSL, false to disable use of SSL. If not specified, false is the default. NOTE: You must also import a trusted certificate chain for Active Directory into the Cams keystore at CAMS_HOME/conf/cams-keystore.jks. For complete instructions on how to do this, please see Using SSL when accessing LDAP user directories. connectTimeout - (optional) The number of milliseconds to wait to establish a Active Directory server connection before timing out the request. This value provides a way to interrupt an attempted connection, which can take nearly 1 minute to fail in cases where the Active Directory host is unavailable due to a network outage. NOTE: To prevent a Cams web agent authentication request timeout from occurring, make sure the connectTimeout value is less than the connection.authentication.timeout value found in a Cams web agent's cams-webagent.conf file.
baseDN - The base distinguished name for the user search. Always in the format cn=Users,dc=domain,dc=com for Active Directory's default schema, where the values domain and com correspond to the domain configured for the particular directory. scope - Specifies the search scope to use. Valid values are BASE (search is done only at the base dn tree node), ONE (search is done only at the first child tree node of the base dn), and SUB (search is done at the base dn node and all child nodes). This value should be set to ONE for most Active Directory sites. filter - The filter to use to search for a user's roles. The UPN will be substituted for the value "{username}". NOTE: Search filters often contain an ampersand character ("&"). To prevent a search filter ampersand from being interpreted by the Cams XML parser as a XML tag, you must substitute the value "&" for any ampersands in the filter. roleAttr - The name of the attribute that contains the group names to be mapped to Cams roles. Use memberOf for convenience (returns all user group memberships except the user's primary group and any nested groups). Use tokenGroups to return all groups of which the user is a member. Use of tokenGroups requires configuration of the Cams Active Directory group name service (see the optional serviceId configuration value). domain - (optional) The Active Directory domain to append to the user name for user convenience and to improve accuracy. If this value is present then the Active Directory login module will append "@" followed by the domain value to the user name to compose the UPN before attempting a bind. An alternative approach would be to perform this concatenation in the login page, perhaps using a select element to enable the user to choose the domain. emptyPassword - (optional) Allow use of empty passwords (false by default). Set this value to true to allow use of empty passwords when Active Directory is configured to allow anonymous binds. defaultRoles - (optional) A comma-delimited list of roles to be assigned to each successfully authenticated user. roleRegexPattern - (optional) Limits roles saved in user sessions to those that match a regular expression pattern. This option is useful when a role search returns many user roles that are not referenced in the access control policy for the security domain. For access control polices with a limited number of roles a regular expression separating role names with the pipe ("|") character is suggested. useRoleSearch - (optional) A value of "true" (default) indicates that a role search will be attempted [true|false]. This option is useful for sites configuring Cams for single sign-on (sometimes to a SharePoint or OWA server using Cams Windows Impersonation) and not role-based access control. useDomainInRoleSearch - (optional) A value of "true" (default) indicates that the optionally supplied domain used for authentication will be included in the role search filter's {username} substitution value [true|false]. This option is useful for sites that have migrated from an NT domain to Active Directory, where accounts may not have a userPrincipalName attribute. In such cases, configuring this value to false and using a role search filter that searches on the sAMAccountName attribute instead of the userPrincipalName is suggested. serviceId - (optional) The unique identifier of the Cams Active Directory group name service (configured in security-domain.xml). This configuration value is required if you set the roleAttr configuration value to tokenGroups. addPrivateCredentials - (optional) A flag that indicates whether or not a java.net.PasswordAuthentication object containing the user name and password should be added to the Subject's private credential set on successful authentication. See Cams IIS Web Agent Guide - Windows Impersonation Configuration for additional information. WARNING: The values in this object are not encrypted and can be accessed by other Cams policy components and web agent. Administrator must ensure that only trusted components are used and have access!
Digipass JDBC Login Module You use the Digipass JDBC login module with VASCO Vacman controller software to verify user entered VASCO Digipass authentication credentials with those stored in a relational flag="REQUIRED"> Options -> Privacy -> Cookies -> View Cookies" to view and remove persistent and memory resident cookies.
Deleting the Cams AUTOLOGIN Cookie The Cams AUTOLOGIN cookie has a configurable expiration period (in days) that will force the user's browser to automatically delete the cookie once the expiration date/time has been passed. A user may also force deletion of the AUTOLOGIN cookie by explicitly clicking a Cams logout URL on the originating web site. Administrators may force deletion of AUTOLOGIN cookies by changing the secret key parameters used to encrypt the cookie value. AUTOLOGIN cookies that cannot be decrypted by the Cams automatic login valve are always removed. NOTE: Though the Cams automatic login and Cams cross DNS domain web single sign-on can be used together, the AUTOLOGIN cookie will only be deleted in the DNS cookie domain in which the user requests logout. If you configure propagation of autologin parameters during CDSSO (configured in the CDSSO valve), an AUTOLOGIN cookie will be created in every cookie domain. When the user explicitly logs out, only the AUTOLOGIN cookie in the "current" cookie domain is deleted. This issue will be resolved when Cams cross DNS domain single logout is implemented.
Configuring Cams Cross DNS Domain Web Single Sign-On Cams supports just-in-time cross DNS domain web single sign-on (CDSSO) using Cams policy server-based components and Cams web agents. The implementation uses an identity (IdP) and service provider (SP) paradigm. After a Cams session is established within a designated IdP cookie domain, session cookies are automatically created for configured SP cookie domains as users visit them, or just-in-time. If a user without an existing Cams session visits a service provider cookie domain first, he is redirected to the identity provider cookie domain to login, then redirected to the originally requested service provider URL after successful login. Additional general information is available in the Cams policy server introductory section Cross DNS Domain Web Single Sign-On. This section provides configuration instructions. The Cams policy server has three components that must be uncommented, enabled, and configured in security-domain.xml to support CDSSO. These components are responsible for: 1. Centralizing CDSSO configuration settings so they are available to authentication and access control services. 2. Handling login to identity and service provider cookie domains. 3. Redirecting users to the identity provider login page if access to a resource is denied because authentication is required. The three components are: 1. service id="jit-http-cdsso-service" 2. auth-valve className="com.cafesoft.security.engine.auth.valves.CamsJITHttpCDSSOAuthValve" 3. access-control-valve className="com.cafesoft.security.engine.access.valves.CamsJITHttpCDSSOAccessControlValve" Details on configuring these components is provided in the following sections, but first let's review the Cams web agent configuration requirements.
Configuring Cams Web Agents as Cookie Providers All Cams web agents are configured by default to act as CDSSO cookie providers. Specifically formatted HTTP GET requests received at a configurable URI are intercepted and handled as CDSSO requests. Example 25 shows the default Cams CDSSO URI value in cams-webagent.conf. We recommend that you leave this value set to the default URI.
# # cams.sso.uri # The Cams web agent interprets GET requests to this URI as a cross # DNS domain single sign-on request. # cams.sso.uri=/cams/sso
Example 25 - Property that configures Cams CDSSO URI in cams-webagent.conf
Configuring the Cams Policy Server CDSSO Service Example 26 shows the Cams CDSSO service component that must be configured within a security-domain.xml file. If you're using the system security-domain.xml file supplied with Cams, this service is already available, but commented out and disabled.
... ...
Example 27 - Configuring the Cams Cross DNS Domain Single Sign-On authentication valve Configure parameters as described below. enabled - set this value to true to enable the valve and to false to disable it. cdssoServiceId - the identity of the CDSSO service configured in section Configuring the Cams Policy Server CDSSO Service. This value must exactly match the id value configured for the CDSSO service.
Configuring the Cams Policy Server CDSSO access-control-valve Example 28 shows the Cams CDSSO access-control-valve component that must be configured within a security-domain.xml file. If you're using the system securitydomain.xml file supplied with Cams, this service is already available, but commented out and disabled.
... ...
Example 28 - Configuring the Cams Cross DNS Domain Single Sign-On authentication valve Configure parameters as described below. enabled - set this value to true to enable the valve and to false to disable it. cdssoServiceId - the identity of the CDSSO service configured in section Configuring the Cams Policy Server CDSSO Service. This value must exactly match the id value configured for the CDSSO service.
Restart the Cams Policy Server and Cams Web Agents After configuring Cams CDSSO options and components, create a role-based access control rule and invoking permission(s) such as those described in Integration Quick Start - Configure a basic access control policy. Your permission should protect at least one web resource on each test SP web site. For simplicity, you might use the same web resource for all test SP sites, such as: /secure/index.html. Remember to restart the Cams policy server and the web servers containing your Cams web agents. To test, use the camstest page included with all Cams web agents. After successful login to the Cams IdP using camstest, you should be able able to visit the secure web resources on the test SP sites without being prompted for login. You can check the camstest page in every SP cookie domain after accessing the secure web resource and see a Cams cookie with the same session identifier as the Cams IdP cookie. Web browsers such as Chrome or Firefox are also useful to view HTTP cookies. You should see Cams session cookies for every SP cookie domain that was both registered for CDSSO and accessed during the test. Each cookie has the same Cams cluster and security domain-specific name prefix, for example: CAMS_SID_MYCAMSCLUSTER_SYSTEM.
Configuring Cams CDSSO Single Logout Cams CDSSO Single Logout (SLO) is configured using a web server script. An example script is provided with each web agent in the scripting language most common to the target web server. Please see Scripts - Cross DNS Domain Single Logout found in the documentation of each Cams web agent for information on the design and integration of the SLO script. Back | Next | Contents
©2017 OneLogin, Inc. All rights reserved.
Terms | Privacy Policy | Site Map
EU |