OpenSSO Data Stores

There are a few data stores which we need to configure in OpenSSO.

1. Authentication Data Store assists in users' authentication

2. Identity Data Store holds the users' profiles

• Usually, there is a 1-to-1 mapping between a user in the authentication data store and a user in the identity data store
• Authentication data can also be stored together with Identity Data Store
• i.e. The Sun LDAP is used for both Authentication and Identity
• The reserve is also true: Active Directory can be configured for both purposes

3. Configuration Data Store is used for storing service configuration data and other information pertinent to the server's operation. Policies are also stored here. 

• We used to store Configuration data in Sun LDAP as well
• However, since version Access Manager 8.x (aka OpenSSO 8.x), these data is now stored in the embedded OpenDS.  
• This embedded OpenDS makes configuration for high-availability easier - less work to do

.

Difference between Web and J2EE Policy Agents

In OpenSSO, there are 2 types of Policy Agent to choose. Customers always get confused on which type and on which tier to deploy in their environment. 

The following diagrams illustrates clearly. Based on the Selection Criteria, Web Policy Agent will be deployed on the Web tier. 

J2EE Policy Agent will be deployed on the Application tier.

PS: If J2EE Policy Agent is deployed on the Application tier, there is no need for Web Policy Agent to be deployed on the Web tier. Simply allow the pass-through on the web server and let the Policy Evaluation be carried out on the Application tier.



.

OpenSSO and Enterprise SSO Selection Criteria

I have been busy involving in the design of a Single Sign-On (SSO) and Enterprise Single Sign-On (ESSO) solution for a local ministry.

They have a few hundreds applications (web-based and non web-based). Thus we need to have a concise selection criteria for them.

There are 2 types of policy agents available from OpenSSO:

1. Web Policy Agent

2. J2EE Policy Agent

In order to integrate applications for Single Sign-On with OpenSSO, they must be:

1. web-based

2. authenticate with a common authentication repository

3. supported by available policy agents from OpenSSO

If applications are customizable, Web Policy Agent will be chosen. Otherwise, if applications are pure J2EE-based that utilize the Java Authentication and Authorization Service (JAAS), then J2EE Policy Agent will be chosen.

If the above 2 criteria cannot be met, then ESSO will be chosen.

.

Automatic spam detection for comments

Salute to Blogger! There is now a feature to automatically detect spam for comments ...

I love this feature since I have been spending time manually removing spammed comments for the past months.

.

Oracle Directory Services Directory Server Enterprise Edition 11gR1

Sun Directory Server Enterprise Edition (DSEE 7.0) has now been rebranded as Oracle Directory Services Directory Server Enterprise Edition 11gR1. It is now part under the Oracle Fusion Middleware umbrella.

Read here.

.

OpenSSO Distributed UI Server & Windows Desktop SSO

For security reason, OpenSSO Distributed Authentication UI Server is recommended to "front" the OpenSSO Server that sits behind the firewall. For better performance, you can deploy multiple DAUI Servers with multiple OpenSSO Servers.

However, do note that if you deploy a Distributed Authentication UI Server in front of your protected OpenSSO Server, then Windows Desktop SSO is not supported.

Read here.

.