Tuesday Apr 28, 2009

Sweet Soul Revue-ing 'Organizing Data in an OpenSSO Realm'

Notwithstanding Maybe You'll Know: Logging in to the OpenSSO Console, here's another chapter from the Sun OpenSSO Enterprise 8.0 Administration Guide that has been rewritten and wiki-ized.

Organizing Data in a Realm basically takes you through the tabs that are used to configure data in a realm - everything under the Access Control tab. The simpler sections are complete in this entry while the more complex sections link to chapters on docs.sun.com (until these chapters are also formatted for wiki).

So what's missing? Is the information organized as you might look for it when using the console? When you read a section are you wanting further information for which there is no link? Remember this is administration information when you read it - not coding or customization.

Thoughts? Comment here or on the wiki.

Coming up: Managing Authentication Using Realms

Sweet Soul Revue is a great pop song from the Japanese band, Pizzicato Five. I had a bunch of P5 albums in the 90s although I never quite knew what most of the lyrics were about. Still got me up on the dance floor!

Wednesday Jul 16, 2008

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.

Friday May 16, 2008

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.



« August 2016