Chat now with support
Chat with Support

Single Sign-On for Java 3.3.2 - Administration Guide

About this guide Introducing Single Sign-on for Java Preparing for Single Sign-on for Java Deploying Single Sign-on for Java
Getting started with Single Sign-on for Java Single Sign-on for Java and your web applications Setting up logging Controlling access to resources
Security Issues Maintenance and Troubleshooting Appendix: Configuration Parameters Appendix: Using the JKTools

Credential delegation

Problem:

Servlet authenticates but there are no delegated credentials (or deleg example displays message “Expected delegated credential but didn't get any”)

Cause 1:

The service account is probably not trusted for delegation

Resolution 1:

See Setup using Active Directory tools.

Cause 2:

The user’s account may be configured so that delegation is not allowed.

Resolution 2:

Check the user's account properties in Active Directory.

Problem:

Delegation to IIS fails, with a MIC check problem.

Cause:

This is because IIS seems to send back a clone of the mechToken in the MIC field, which causes MIC-checking to fail.

Resolution:

Setting the system property idm.spnego.noMICcheck to true disables MIC checking.

Debugging

Problem:

How do I get more debug information out of Single Sign-on for Java?

At the lowest level setting the Java system properties jcsi.kerberos.debug to the value true and idm.spnego.debug to the value true should produce logging to the standard error output stream.

Single Sign-on for Java Servlet Filter is configured on a per web application basis. This configuration is based upon log4j and defined in the Web application’s web.xml deployment descriptor.

Appendix: Configuration Parameters

This appendix includes a detailed list of configuration parameters for Single Sign-on for Java operations, including those involved directly in Single Sign-on for Java (naming convention idm.*) and those related to system properties relevant to Single Sign-on for Java.

Single Sign-on Configuration Parameters

Table 10: Configuration parameters

Parameter

Description

idm.principalAtRealm

 

This parameter should be set to the fully qualified name (including the Active Directory domain) of the Single Sign-on for Java service principal you have set up (see Setting up the service account) — for example, vsj_appservhost1@EXAMPLE.COM.

Not needed if the idm.keytab points to a keytab exclusively containing entries for the Single Sign-on for Java service principal.

idm.realm

 

The Active Directory domain to be used for authentication. Its use is now deprecated in favour of the preferred idm.principalAtRealm parameter (see above). Not needed if the idm.keytab points to a keytab exclusively containing entries for the Single Sign-on for Java service principal.

idm.princ

 

The Kerberos service principal to use. Use of this parameter is also deprecated in favor of the preferred idm.principalAtRealm parameter above. Not needed if the idm.keytab points to a keytab exclusively containing entries for the Single Sign-on for Java service principal.

idm.keytab

 

The file containing the keytab that Kerberos will use for user-to-service authentication.

If unspecified, Single Sign-on for Java defaults to using an in-memory keytab with a password specified in the com.wedgetail.idm.sso.password custom property or the idm.password parameter.

idm.password

 

The password of the service account specified by idm.principalAtRealm. Single Sign-on for Java creates an in-memory keytab using this password.

NOTE: This parameter is required if the idm.keytab parameter or com.wedgetail.idm.sso.password property is not set.

idm.allowS4U

 

Boolean logic value (true/false) to toggle the use of S4U2Proxy (Constrained delegation) and S4U2Self (Protocol transition) in Single Sign-on for Java operations.

Default is false.

idm.allowNTLM

 

Boolean logic value (true/false) to specify whether to allow fallback to NTLM authentication. This is required if you want to use the SSO solution with pre-Windows 2000/XP Internet Explorer browsers which do not support SPNEGO.

The default is false.

idm.allowFallback

 

Boolean logic value (true/false) to specify whether to allow fallback to basic authentication.

The default is false.

idm.allowUnsecured

 

Boolean logic value (true/false) specifying whether to allow authentication over an unsecured channel.

It is strongly recommended that you do not be set this to true unless there is a very low risk of an attacker accessing the communication channel between the client and server.

The default, if not set, is false.

*idm.userHandledExcept

 

Boolean logic value (true/false). Setting this parameter to true propagates exceptions from Single Sign-on for Java code to the Web server so that you can write your own error pages based upon the Single Sign-on for Java error that occurs.

*idm.kdc

 

The Active Directory key distribution center (KDC) against which secondary credentials should be validated This can be used for basic fallback, or credential delegation.

By default, the KDC is discovered automatically and this parameter should only be used if automatic discovery fails, or if a different KDC to the one discovered automatically should be used.

idm.fallbackCrossRealm

 

Boolean logic value (true/false). If this parameter is set, Single Sign-on for Java attempts to guess the client's realm from the domain part of the hostname returned by ServletRequest.getRemoteAddr(), and the user is not required to append the realm to their username. By default this is false.

idm.supportMultipleSPN

 

Boolean logic value (true/false). Specifies whether to support multiple service principal names. If this option is set to true, the server uses the service name in the ticket to determine which key to use for decryption. The default is false. See Setup using Active Directory tools.

*idm.ad.site

 

The name of the Active Directory site in which this server should be placed.

*idm.ad.login

 

The username used to access Active Directory user information via simple authentication.

If specified, it should be the fully-qualified user created for the service principal as described in Setup using Active Directory tools (for example, user@EXAMPLE.COM).

*idm.ad.security

 

This parameter specifies how connections to LDAP servers are secured. Possible options are sasl and simple.

idm.access.policy

 

Specifies the file from which access policies for authorization will be read. If unspecified, access must be handled programmatically.

idm.access.groupsAsRoles

 

Boolean logic value (true/false). If a given role is not associated with any users, it treats the role as an Active Directory group. By default this is false.

idm.ad.userPrincipalAttribute

 

This parameter can be set to the name of an Active Directory attribute.

If set, the value of this attribute will be made available to web applications rather than the user name that was authenticated. This could be used to allow a user to login normally with username and password but then be known to the web application by perhaps an employee id, which is stored and managed in Active Directory.

This property takes precedence over idm.ad.qualifyUserPrincipal but yields precedence to idm.ad.userPrincipalFormatterClass.

idm.ad.qualifyUserPrincipal

 

Boolean logic value (true/false). Set this to fully qualify the authenticated user name returned by Single Sign-on for Java that is, append the Active Directory domain name. The idm.ad.userPrincipal attribute and idm.ad.userPrincipalFormatterClass properties take precedence over this one.

The default, if not set, is false.

idm.ad.userPrincipalFormatterClass

 

The class name of a com.wedgetail.idm.sso.UserPrincipalFormatter implementation to use for formatting principal names returned by Single Sign-on for Java. This property takes precedence over both idm.ad.userPrincipalAttribute and idm.ad.qualifyUserPrincipal.

idm.ntlm.signing.username

 

The NTLM logon name of a user account that Single Sign-on for Java can use for NTLM signing.

idm.ntlm.signing.domain

 

The NTLM domain (not the AD domain) to which the above user account belongs.

idm.ntlm.signing.password

 

The password for the above account.

idm.ntlm.signing.always

 

Boolean logic value (true/false): true means that Single Sign-on for Java should always use these signing parameters.

false means that Single Sign-on for Java should only use these signing parameters if it got an exception while trying to authenticate a user without using these signing parameters.

The default value (true) is recommended.

idm.trimUnsolicitedBasic

 

Boolean logic value (true/false) used for tuning. Optimize unnecessary HTTP Basic reauthentication. The default is false.

If this is true and a client sends us an Authorization: Basic header when we don't need it (because we have already authenticated the client) then we ignore the header.

If this is false, we process the header (and reauthenticate the client) even though we don't really need to.

This parameter is never harmful but only helps performance in the unusual case where a client sends Basic authentication much more often than necessary (for example, on every request).

idm.trimUnsolicitedNTLM

 

Boolean logic value (true/false) used for tuning. Optimize unnecessary HTTP NTLM reauthentication.

The default is false.

If this is true and a client sends us an Authorization: NTLM header (or NTLM dressed up as Negotiate) when we don't need it (because we have already authenticated the client) then we process it just enough to humour the client — because otherwise Internet Explorer won't send us the body of a POST or PUT request.

But we don't bother to perform the last, rather expensive, step of NTLM authentication: contacting a domain controller to validate the NTLM password hashes.

If this is false we process the header completely and reauthenticate the client even though we don't really need to.

It is generally a good idea to enable this option if idm.allowNTLM is enabled and a significant percentage of your HTTP NTLM requests are POST or PUT (because Internet Explorer reauthenticates on every HTTP request with a content-body, such as POST or PUT).

There are no known disadvantages to enabling this option.

idm.trimUnsolicitedSPNEGO

 

Boolean logic value (true/false) used for tuning. Optimize unnecessary HTTP SPNEGO reauthentication.

The default is false.

If this is true and a client sends us an SPNEGO token in an Authorization: Negotiate header when we don't need it (because we have already authenticated the client), we ignore the header.

If this is false we process the header (and reauthenticate the client) even though we don't really need to.

This option is only necessary if a significant percentage of your HTTP SPNEGO requests are POST or PUT — because Internet Explorer reauthenticates on every HTTP request with a content-body, such as POST or PUT —and the CPU overhead of the unnecessary SPNEGO/Kerberos reauthentication operations is becoming prohibitive.

Note: if this option is enabled, Single Sign-on for Java does not send an SPNEGO response token (NegTokenTarg). This is fine for Internet Explorer, but may or may not be fine for other clients.

idm.ntlm.userCache.maxSize

The maximum number of entries in the NTLM user cache.

idm.ntlm.userCache.maxAge

 

The maximum lifetime (in milliseconds) of entries in the NTLM user cache.

This value only needs to be large enough so that repeated authentications for the same NTLM user over a short period (for example, by HTTP clients that don't support JSESSIONID cookies) will use the cache instead of triggering repeated expensive lookups for the same information.

The default is ten minutes (600000 millisecs).

idm.disableTicketSanityCheck

 

Boolean logic value (true/false). Normally when Single Sign-on for Java starts it up it contacts Active Directory to check that idm.principalAtRealm (or idm.principal and idm.realm) and idm.keytab or idm.password are valid. If they aren't valid, Single Sign-on for Java reports the problem and gives up.

If you need to disable this check, set this boolean parameter to true.

Default is false.

idm.propertyFileURL

Parameter for specifying the URL of the property file.

idm.allowServerTGT

 

Boolean logic value (true/false). Allow code in the web application to obtain and use Single Sign-on for Java's own TGT. The web application may need this if, for instance, it wants to perform LDAP queries to Active Directory which go beyond the LDAP functionality that Single Sign-on for Java provides.

idm.logger.name

 

Specifies the unique name of the logger. This must match the name in any related Log4J properties file.

idm.logger.props

 

Specifies the file from which Log4J properties should be loaded for logging. If no properties file is specified, errors are logged to the servlet-context log by default.

Note: Parameters marked with * are legacy parameters and generally should not be used.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating