Complex sets of resources must be logically grouped so that security policies can be created. The basic CA SiteMinder® groupings for resources are realms.
A realm is a cluster of resources within a policy domain grouped according to security requirements. A realm is usually defined for resources that reside in a common location on your network. For example, marketing information that resides in a /marketing directory on your network might be configured as a realm in a policy domain controlled by an administrator in your company’s marketing organization.
The contents of a realm are protected by Agents. When users request resources within a realm, the associated Agent handles authentication and authorization of the user. The realm determines the method of authentication.
The following diagram shows the contents of two realms.
Each of the realms contains resources, such as HTML files, forms, or applications. In addition, each realm is associated with an Agent and an authentication scheme.
If CA SiteMinder® 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:
Note: CA SiteMinder® 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.
The resources protected by CA SiteMinder® are identified by the following:
[Agent] [Realm Resource Filter] [Rule Resource]
An Agent monitors a server that contains one or more realms of protected resources.
A 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
A 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:
<document_root>/HR
For the Policy Server, the following figure shows the effective resource.
You could configure the directory called Managers as a nested realm under the /HR realm.
To access the protected page PayRanges.html, under the Managers subdirectory, a user would need to:
http://MyHost.myorg.org/HR/Managers/PayRanges.html
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 SiteMinder® 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:
|
Action |
Protection State |
|
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.
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.
|
Copyright © 2014 CA.
All rights reserved.
|
|