Tuesday Apr 28, 2009
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
By docteger on Jul 16, 2008
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.
- 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.
- 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.
Friday May 16, 2008
By docteger on May 16, 2008
When you deploy OpenSSO in your favorite web container,
openssois 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.
- 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
- Create a subrealm under
- Under the
openssoroot realm, create a policy referral with the Resource Name defined as
- Under the
paychecksub-realm, create a group under Subjects called
PaycheckAdminand select the appropriate privilege (Read and write access only for policy properties) under Privileges.
- 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.
paycheckwill 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.
- Create a subrealm under
- 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.
- Eyes Only: OpenSSO Express 9 Documentation
- Sun & Oracle: EU Has No More Tears
- Using OpenSSO with Microsoft Geneva Server
- Managing OpenSSO Entitlements Using REST: The End
- Evaluating OpenSSO Entitlements Using REST
- Listening for the OpenSSO Entitlements Service Using REST
- Authenticating for the OpenSSO Entitlements Service REST Interfaces
- Born To Change a Configured OpenSSO Host Name
- Happy New Year Authenticating to OpenSSO Monitoring Service
- Importing the Root CA Certificate for Secure OpenSSO Rainbow Connections