A Realm is a Bin for Data When You Need to Store

When you deploy OpenSSO in your favorite web container, opensso is configured as the root realm. A realm (under the Access Control tab) is a group of authentication properties and authorization policies that can be associated with a user or group of users, or a collection of protected resources. For example, you can create a realm that groups all servers and services accessed by employees in one region. Within that regional realm, you can group all servers and services accessed regularly by employees in a specific division, such as Human Resources. And even more fine-grained, you can add constraints that allow users to access a particular service from Monday through Friday, 9:00 a.m. to 5:00 p.m.

The root realm is where you configure user (identity) data stores, manage policies and create authentication chains globally. A Realm Administrator can do all these operations in the root realm while the Policy Administrator can only create and manage policies. Under the root realm, you configure sub-realms. Sub-realms enable the following scenarios.
  1. You need an administrator who can create policies for a sub-set of resources only. For example, let's assume you want an administrator to create policies for resources that reside at https://paycheck.sun.com/paycheck.

    1. Create a subrealm under opensso named paycheck.
    2. Under the opensso root realm, create a policy referral with the Resource Name defined as https://paycheck.sun.com/paycheck.
    3. Under the paycheck sub-realm, create a group under Subjects called PaycheckAdmin and select the appropriate privilege (Read and write access only for policy properties) under Privileges.
    4. Modify the appropriate user profile and policy under the sub-realm to reflect this new privilege and the user can then login to the sub-realm and create policies for the defined resources. The sub-realm, in this case, is mainly for the policy administrator to manage the policies for the configured resources.

    By default, paycheck will have the same data store and authentication chains as opensso, its parent realm. If configurations change in the parent realm, a corresponding change in the sub-realm policy might be needed.
  2. You need each sub-realm to have its own set of data stores (identities), authentication chains and policy administrators. Ideally there would be nothing in common between the root and the sub-realm except for the referral policy created under the root realm to delegate all, or a subset of, resources to the sub-realm. With this scenario, users would be created within, and authenticate to, their sub-realm. Agents would also have to be configured to redirect user authentication to the sub-realm.

Regarding performance, the most resource-consuming component of the realm architecture is the persistent searches done using the one data store in the first scenario. This is not really an issue in the second as the searches go to different directories. A guess on the number of sub-realms that can be supported would be about 100 for the first scenario and about 50 for the second.

And although a realm is a bin for data when you need to store, remember that a dream is a wish you heart makes when you're fast asleep. Sing along below but not too loud if you're in an office with the door open.

Oy, did I really just post a music video from Cinderella? Should I have posted something from La Cenerentola to show how couth I am? Maybe but unfortunately I don't understand Italian and thus couldn't find a cute title for this entry a la Rossini.
Comments:

[Trackback] Bookmarked your post over at Blog Bookmarker.com!

Posted by store on May 17, 2008 at 09:50 PM PDT #

Hi Doc,

You're the only I know jumping from Shirley Bassey to Cinderella ;-) but your posts are always worth reading !
Thanks for the good job.
Seb

Posted by Sebastien Stormacq on May 18, 2008 at 02:37 AM PDT #

Thanks, Sebastian. My musical tastes are all over the map and I like to pass on this amalgamation to others. I'm glad you enjoy the music and the information.

Posted by DocTeger on May 19, 2008 at 12:30 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