Single Sign-on for Java requires that the application be associated with a user account and provided with either a password, or a keytab file (see Creating keytab files) stored on the server. A keytab file contains a list of one or more keys that can be shared as part of the process of Kerberos authentication. Each key is unique to a particular authenticating user or service.
idm.password and com.wedgetail.idm.sso.password are intended to be convenient for initial setup and debugging in a test environment. Once Single Sign-on for Java is up and running happily with the password, we recommend using a keytab instead.
Similarly, while the keytab file location is specified by a parameter in the deployment descriptor, it must be stored at an absolute location on the server, and not in the EAR/WAR file. This is because commonly there may be multiple copies of EAR/WAR files created by developers/deployers lying around with sensitive passwords in them, or they may be deployed in the clear over unsecured links.
In all cases, care must be taken to ensure that applications that should not have access to this information are either not deployed on the same server, or have their access barred by enabling the Java security manager. If you choose to do the latter, you need to configure your Java security policy file to grant various permissions.
Many Java EE developers are used to deploying applications and just creating a username and password for those users who need to access the application. However, with Single Sign-on for Java, unless you want everyone with a desktop login in your organization to access the application, you need to define some authorization groups to control access.
Single Sign-on for Java uses group information in the PAC of the service ticket to authorize users. However, this group information only lists the SIDs and not the names of the groups which are specified in the authorization policy.
To resolve names, Single Sign-on for Java needs to contact Active Directory via LDAP. In most cases it only needs to do this once at load time.
However, if you are using some of the programmatic functions to access group information, this may also happen at run time.
The information in the PAC is securely authenticated as part of the ticket. However, the mapping between SIDs and the group names they represent must be done securely.
Otherwise, an attacker could substitute their own name for SID mappings and subvert the authorization mechanism. For this reason the connections between Single Sign-on for Java and the Active Directory LDAP servers need to be secured.
By default, connections to Active Directory are secured using the standard SASL/GSS-API mechanism.
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Termini di utilizzo Privacy Cookie Preference Center
