Using Sub-Realms in OpenSSO Again & Again

In general, you should use the default root realm (opensso) to configure identity data stores, and manage policies and authentication chains. After deployment, OpenSSO creates a Realm Administrator who can perform all operations in the configured root realm, and a Policy Administrator who can only create and manage policies. The use of sub-realms in OpenSSO should be restricted to the following two scenarios.
  1. Application Policy Delegation The use case for this is when you need to have different Policy Administrators to create policies for a sub-set of resources. For example, let's assume a sub-realm is created and named Paycheck. This sub-realm is configured with a policy referral from the root realm for configuring protection of resources starting with https://paycheck.sun.com/paycheck. Within the Paycheck sub-realm, a Paycheck Administrator role or group is created and assigned Policy Administration privileges. These administrators are now able to login to the sub-realm and create policies for their applications. By default, the sub-realm inherits the same configuration data store and authentication chains configured for its parent; if these configurations change in the parent, a corresponding change would be needed in the sub-realm. Additionally, all users will still log in to the root realm for access to all the applications. The sub-realm is primarily for the Policy Administrator to manage policies for the application. An educated guess on the number of sub-realms that can be supported would be about 100.
  2. ISP/ASP/Silo The use case for this scenario is when each sub-realm is to have its own set of identity data stores, authentication chains, and policies. Ideally the only common thread between the root and the sub-realm would be the referral policy created in the root realm to delegate a set of resources to the sub-realm. Users would not be able to log in to the root realm (unless they are a member) but would have to authenticate to their sub-realm. Also, agents would have to be configured to redirect user authentication to the particular sub-realm. With regards to performance, the most resource consuming component would be when persistent searches created by the data stores connect to the same directory. An educated guess on the number of sub-realms that can be supported would be about 50.
So now you know how to use sub-realms again & again as confirmed by The Bird and the Bee in their song titled (what else) Again & Again.

Comments:

Its probably worth to point out that if the root realm is used and Authentication configuration is altered you could end up hosing your installation. Thanks for this and other great blogs.

Posted by Anish on July 16, 2008 at 01:18 AM PDT #

You are quick, Anish, but that's some important info to point out so thank you. And I'm glad you find the blog helpful - I try.

Posted by DocTeger on July 16, 2008 at 01:24 AM PDT #

Would either you or Anish elaborate on what he means when he says "if the root realm is used and Authentication configuration is altered you could end up hosing your installation"?

Specifically what kinds of changes could cause damage? What would be the nature of that damage?

Thanks

Posted by Scott on October 13, 2008 at 02:18 AM PDT #

A realm can have sub-realms and it appears that a sub-realm can also have sub-realms. If I apply a policy at the realm level, it automatically applies to a first sub-realm, but does it also automatically apply to the a sub-realm below that first sub-realm?

Posted by Paul on June 09, 2009 at 06:00 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today