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

Group scopes

Each group has a scope which describes both its visibility to other users and applications throughout the enterprise, and the types of principals that can be included in the group. The three group scopes are listed below:

  • Domain Local: Visible only within a domain, and to sub-domains. Domain local groups can include any other type of group, but cannot be included in any of the other groups. Commonly, Domain local groups are used to define the groups and users allowed to access a given local resource.
  • Global: Visible throughout the enterprise, but can only include other users and groups within the same domain (or a parent domain). Global groups should be used to divide users within a domain into categories according to their roles or job functions.
  • Universal: Visible throughout the entire enterprise. Universal groups may include both other Universal groups, and global groups from any domain in the enterprise. For reasons described below, Universal groups are expensive to use, so try to limit the number of these groups. You should use a Universal group wherever it is necessary to create a group that spans one or more domains.

Active Directory allows nested groups (groups that contain other groups), which can be nested to arbitrary levels. This is convenient, as it provides a way to hierarchically manage users. For example you can have a group for each type of manager in a department, and then create a group called Managers that includes all of these sub-groups.

Groups and the log on process

When a Microsoft Windows user logs on to an Active Directory domain, Active Directory builds a token called a Privilege Attribute Certificate (PAC). The PAC contains the list of all the groups the user is a member of, and that are visible in the login domain. This list is a “transitive closure”, meaning it includes any groups which the user is a member of due to nesting of other groups. For example, supposing we have the following global groups which contain the users “Alice” and “Bob”:

  • Group1: contains Alice, Bob
  • Group2: contains Group1
  • Group3: contains Group2

Then the PAC for Alice will contain Group1, Group2 and Group3.

Computing this group membership can take some time and Active Directory may have to query several LDAP servers to determine membership. In addition, Universal groups require a full search of the global catalog, which stores information about every Active Directory object. For this reason, the number of Universal groups should be limited to ensure that logon times do not become too long.

The PAC exists for the lifetime of the initial TGT obtained at logon time (typically 10 hours). For this reason, if a user is added to a new group, the user must log off and then log back on for this group to be used.

Groups and Single Sign-on for Java

When a user accesses an application protected with Single Sign-on for Java, the browser contacts Active Directory to obtain a service ticket for the server which it needs to contact, or retrieves it from the cache if it is available there.

This service ticket contains a PAC containing all the Universal and Global groups from the user's existing PAC, plus any Domain Local groups defined in the server’s domain.

Single Sign-on for Java can then use the groups defined in the PAC to authorize access to a particular resource. Because the group membership is securely authenticated in the PAC, Single Sign-on for Java can trust this information.

Using the PAC also saves time associated with the LDAP lookups needed to recursively resolve group membership, resulting in a more scalable solution.

Active Directory sites

Sites represent the physical topology of your Active Directory infrastructure based on sub-nets of TCP/IP addresses. They allow for replication, redundancy and load balancing across your Active Directory deployment.

By defining sites in Active Directory, you effectively tell it what your underlying physical network looks like. This allows domain controllers to utilize the underlying network in the most efficient manner possible. It allows Active Directory to conserve bandwidth that is required for other applications within your organization.

However, sites are not related to the structure of the domain, nor do they have to maintain the same namespace — a site may span multiple domains and, conversely, a domain may span multiple sites. While no formal relationship exists between a site and a domain, a site may be given the same boundaries as a domain.

To ensure rapid and reliable network communication, Active Directory offers methods of regulating inter-sub-net, or inter-site, traffic.

The Active Directory physical structure governs when and how replication takes place. As users log on to the network, they are able to reach the closest domain controller site through the previous assignment of sub-net information. The system administrator uses the Active Directory Sites and Services snap-in to manage the topology of replication services.

Single Sign-on for Java supports replication and failover using Active Directory sites.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating