The content in this section introduces realms and describes how to configure them. Use the Table of Contents to access the content.
Complex sets of resources must be logically grouped so that security policies can be created. The basic groupings for resources are
realms. A realms can contain resources, such as HTML files, forms, or applications. A realm is a collection of resources within a policy domain grouped according to security requirements. A realm is usually defined for resources in a common location on your network. For example, marketing information that resides in a marketing directory can be configured as a realm in a policy domain. The domain is controlled by an administrator in the company marketing organization.The contents of a realm are protected by Agents. When users request resources in a realm, the associated Agent handles authentication and authorization of the user. The realm determines the method of authentication. Each realm is associated with an Agent and an authentication scheme.
Confidence Levels Introduced
If CA Single Sign-On is integrated with a supported risk analysis engine, you can configure a realm with a confidence level. A confidence level represents credential assurance, which is the likelihood that the user requesting the protected resource is legitimate.Consider the following items:
- A confidence level is based on a numeric scale (0–1000). A higher confidence level corresponds to a higher level of credential assurance.
- When an authentication scheme that generates a confidence level authenticates a user, the confidence level is inserted into the session ticket of the user. The user can access any resource requiring a confidence level equal to or greater than this value, as long as the policy or application applies to the user.
- The factors on which a confidence level is calculated are based on the data the risk analysis engine uses to determine credential assurance.
Note:CA Single Sign-On supports an integration with an on–premise implementation of CA Arcot WebFort and CA Arcot Risk, and a hosted implementation of CA Arcot A–OK.
Identify a Resource by Agent, Realm, and Rule
The resources protected by CA Single Sign-On are identified by the following:[Agent] [Realm Resource Filter] [Rule Resource]
- AgentAn Agent monitors a server that contains one or more realms of protected resources.
- Realm Resource FilterA string, such as a relative path to a directory, that specifies the resources covered by the realm. If the realm is a top-level realm, specify the resources relative to the server that serves up the files or application. If the realm is nested, specify the resources relative to the parent realm. For example, the realm might cover the contents of a directory that is immediately below the document root of a Web server, such as: <document_root>/HR Here, you could specify the realm resource filter as: /HR
- Rule ResourceA string or regular expression that specifies the resources to which the rule applies. Specify the resources relative to the realm containing the resource. For example, if the realm resource filter ends with a directory name, the rule resource might include a subdirectory of the realm directory and even the name of a file in that subdirectory, such as: /Managers/PayRanges.html You can use wildcards to broaden the specification of a rule. For example: /Managers/*
Combining the three elements, suppose that:
- The Agent called MyAgent protects a Web server on host MyHost, in domain myorg.org.
- You want the realm to cover the contents of the following Web Server directory: <document_root>/HR
- The HR directory contains a subdirectory called Managers, and you want to protect all files in the subdirectory.
You could configure the directory called Managers as a nested realm under the /HR realmTo access the protected page PayRanges.html, under the Managers subdirectory, a user would need to:
- Specify the resource: http://MyHost.myorg.org/HR/Managers/PayRanges.html
- Provide credentials for a user authorized to access the resource. Administrators use policies to specify which users are authorized to access a resource.
Unprotected Realms, Rules, and Policies
By default a realm is created in a Protected state. In most cases, you should use protected realms instead of changing a realm to an Unprotected state. In a protected realm, all resources are protected against access. To allow access, a rule must be defined, then included in a policy.When you create a realm in an Unprotected state, you must configure rules before CA Single Sign-On protects the resources in the realm. If you create a rule for resources in the unprotected realm, only the specified resources are protected. Once the resource is protected, the rule must be added to a policy to allow users to access the resource. You may want to use an unprotected realm if only a subset of the resources in a realm need to be protected from unauthorized access.The following is an example of the actions required when setting up an Unprotected realm:
Create unprotected realm called Realm1 with the Resource Filter: /dir.
Resources contained in /dir and subdirectories are not protected.
Create Rule1 in Realm1 for the resource: file.html.
The file /dir/file.html is protected, but the rest of the contents of /dir are not protected.
Create Policy1 and bind Rule1 and User1 to the Policy.
User1 can access /dir/file.html. All other users cannot access the protected file.
Note:If you want to track users for a realm with an Anonymous authentication scheme, the realm must be a protected realm. For information about the Anonymous scheme, see Anonymous Authentication Schemes.
Realms represent groups of resources in much the same way that directories of files and folders represent a file system’s contents. Nested realms allow you to increase the protection level of resources that are lower in a directory tree. Below any existing realm, you can create a nested realm. You can then assign an authentication scheme with a higher protection level to the nested realm.By default, to access resources in the child realm, a user must be authorized for resources in the parent realm and for resources in the child realm. You can globally change the default behavior of the Policy Server and always allow access to the resources in the child realm for users who are authorized either for the parent realm or the child realm. However, we do not recommend changing from the and logic to the or logic, which is less secure. To change to the or logic, remove the check from the Enable Nested Security check box.
Note:Do not assign the anonymous authentication scheme to any realm in a nested structure, including the top-level realm. You can’t authorize specific users for resources protected by an anonymous authentication scheme, so the and logic will fail.
The following example illustrates how nested realms can be used to provide increasing levels of security.
In the realm structure shown in the previous figure, the realms mimic the file structure of the resources. Each of the nested realms has a different authentication scheme than its parent realm. Since the authentication scheme for each child realm has a higher protection level than that of the parent realm, users will need to re-authenticate when they try to access resources at lower levels of the tree. To implement this example, for each realm, you need to create a rule. Then, you need to create corresponding policies so that each policy contains a rule and users that need to access resources in a child realm can also access resources in the parent realm.
Note:Only administrators with the Manage System and Domain Objects privilege may create, edit, and delete realms. However, administrators with the Manage Domain Objects privilege may create, edit, and delete nested realms underneath existing realms in their policy domains.
Realms in Request Processing
When a user requests a resource, the Policy Server uses the longest matching realm to determine if a resource is protected, and if so, which authentication scheme must be used to establish the user’s identity. The longest matching realm consists of the resource filter that can be located in the deepest level of any group of nested realms (or a single realm if nested realms are not used) that matches the requested path to a resource.
Using the example from the previous section, a file called list2.html in the location /marketing/competitors/list2.html matches the nested realm /marketing/competitors/. When the Policy Server processes authentication for list2.html, the user authenticates via HTML Forms, since that is the authentication scheme associated with the /marketing/competitors/ realm.
In the same example, a file called current_budget.html in the location /marketing/budgets/current_budget.html. Since the /budget directory is not specifically called out in a nested realm, the longest matching realm for this resource is /marketing/. Therefore, the user authenticates via the Basic user name and password authentication scheme.