Currently, the SAMLv2 Service servlets are always listening. For example, if you don't want to use the Artifact Resolution Service or the Manage Name ID Service it is still on. To switch the services off, you can remove the endpoints from the entity provider's configuration.
Log into the OpenSSO console as administrator.
Click the Federation tab.
Click the name of the entity provider for which you want switch off a particular SAMLv2 Service.
Click the Services tab.
Remove the appropriate endpoint.
Click Save.
You can also use the ssoadm command line interface.
Use ssoadm export-entity to export the extended metadata.
Modify the exported extended metadata.
Use ssoadm delete-entity to delete the original extended metadata.
Use ssoadm import-entity to import the modified extended metadata.
Disabled services return an HTTP error code.
Interestingly enough, after I titled this entry using the B-Movie single Switch On Switch Off, I was unable to find a video for that song anywhere. (It was a failed single but really this IS the internet.) In absentia, here is B-Movie's biggest hit (of which there are plenty of videos) Nowhere Girl.
3743
Jim Faut
and Rick Palkovic have been posting a nice series on how to troubleshoot
OpenSSO
with Firefox Add-Ons.
They just pushed out two more entries in the series, which now includes:
These articles are worth a check even if you just want to learn about how OpenSSO works:
just follow their diagrams to see
the exchange of information between the parties that enable these features.
I'm going to stand on my soap box for a few minutes to share my take on the ongoing dialogue around RBAC versus ABAC. The debate over which one is better seems to be as heated as the debate over which side of a black and white cookie tastes better (Seinfeld - Black & White Cookie Episode).
I'm constantly asked by customers about which approach I prefer. Analysts seem to enjoy this conversation as well. In fact, Kuppinger-Cole did a nice Q&A on the debate earlier this week and does a great job outlining the issues.
Critics of the RBAC model argue that RBAC is static and believe that taking an RBAC-only approach will lead to an excessive number of roles. They argue that policy decisions will need to leverage Roles plus attributes embedded within your application infrastructure.
Honestly, I think the debate here is somewhat self-created by framing it in terms of RBAC versus ABAC rather than simply acknowledging that a good policy engine needs to support both roles and dynamic attributes. It is very rare to come across customers that are able to contain all attributes within a role. I have yet to see a real-world organization with a clean RBAC implementation. Arguing for purely RBAC is a nirvana that casts a blind eye to the grey areas of the application infrastructure world.
The issue of RBAC v. ABAC is less a decision about choosing one over the other and more a decision around where one draws the line when defining roles. Todays organizations need to define a clear line between what attributes should be part of a role and what should remain application specific. The balance between how you define roles versus attributes is very use case driven and contextual to each customers environment. This boundry is often based more on business context, IT budget, perceived value of abstracting identity from apps, and a gazillion other factors that could influence what you should do.
From the perspective of entitlement enforcement, the basic jist is that any system that is going to work for a customer needs to support both ABAC and RBAC. Policy enforcement decisions need to take in to consideration role definitions and sometimes they also need to incorporate dynamic attributes from applications.
As we refine entitlement enforcement in OpenSSO (our Beta was made available in September 2009) we are looking at this from both perspectives and expecting real implementations to require a hybrid solution that is dynamic and can take in to consideration both roles and attributes. Our solution consumes roles, allows applications to push attributes to OpenSSO for policy evaluation, and allows OpenSSO to pull attributes for policy evaluation. In fact, OpenSSO also supports policy referrals or partial policy referrals to help make an "accept" or "deny" decision.
Thus, my solution is to stop arguing about RBAC versus ABAC and change the name to ARRRRRRRRR-BAC (use the best pirate voice you can muster). Thus, like the black and white cookie, we can all live together again in harmony.
Yesterday, Neil Ghandi, Matt Hamlin, Etienne Remillon and I gave a quick overview of what is new in Directory Server Enterprise Edition 7 and Role Manager 5. Here are just a few of the great highlights that were discussed during the presentation. Of course, you can get the full video embeded below. Lastly, if you are interested in seeing more events like this you can go to the webinar site here.
You can download the slides here. You can download the video here.
Someone (who shall remain nameless) did the unthinkable and changed the status of the / Top Level Realm to inactive. After doing this, someone could no longer log in to the console. So how did someone rectify this situation?
Someone used an LDAP browser, found the ou=services,dc=opensso,dc=java,dc=net field and changed the value back. Now remember...don't actually do this but at least there is a way to undo it.
And now here's Connie Francis singing her hit Vacation in Japanese. Who knew?
There were series of mails from our IT department warning us about servers being decommissioned. But first I postponed the needed, then forgot, and then ignored the FINAL WARNING. What happens... My lack of action bit me back and my solaris box was unusable
Having grown up with windows machines, unix is something I am still getting used to. So I was so scaared of what happens
But it turns out that, the IT team had done a pretty good document which guided us step by step. And in course I also learnt a couple of new things
- ypwhich - gives the NIS server the machine is currently using -- you can also try "ypwhich another-machine-on-nw"
- /etc/resolv.conf - Defines which naming server to use Eg - nameserver 129.147.9.5, where 129.147.9.5 is the ip address of the naming server used
The goal of this document is to enable the reader to be able to
protect their Java EE application deployed on Glass Fish Enterprise
Server 2.1 Cluster using OpenSSO and Policy Agents 3.0. This document
is verified and validated with OpenSSO policy agents 3.0 and GFv2.1 EE
cluster as described in the next section. Read more on
Some new attributes have been added to the OpenSSO Administration Console and are available now in the nightly builds.
Prompt User for Old Password is a flag that will do just that - add a text field to the Change Password page that would require a user to enter the old password when changing it. The attribute is located under the top level Configuration tab. Underneath the Configuration tab, click the Console tab and then the Administration link. It is in the Realm Attributes section. If not checked, the old password will not be required. This is the default behavior. If checked, the behavior is dependent upon whom is changing the password: the administrator or the end user.
If an administrator is changing the password for the end user, the old password is not required. The Prompt User for Old Password text field will be grayed out and the password will be changed by calling the getIdentity method in com.sun.identity.idm.IdUtils.
If the end user is changing the password on their own, the old password will be required. The Prompt User for Old Password text field will be enabled and, after it has been entered, the password will be changed by calling the changePasswordmethod in com.sun.identity.idm.AMIdentity.
Requested Key Type allows you to define the key system used by the STS Client profile defined; for example, the default SecurityTokenService. The attribute is located under the top level Access Control tab. Under the Access Control tab, click the appropriate realm link, then the Agents tab and then the STS Client tab. Click the name of the profile you are configuring to see the attribute under the Security section. You can choose Public Key (two keys are used - one to encrypt the data and one to decrypt the data) or Symmetric Key (one key is used to encrypt and decrypt the data).
A SAML Configuration section has been added to the STS Client and Web Service Client agent profiles to help configure the SAMLv2 protocol. (The section already exists for the Web Service Provider agent profile.) The section is located under the top level Access Control tab. Under the Access Control tab, click the appropriate realm link, then the Agents tab and then the STS Client tab or the Web Service Client tab. Click the name of the profile you are configuring to see the SAML Configuration section link. The section includes the following attributes.
SAML Attribute Mapping: This configuration maps the SAML attribute in an assertion from an incoming web service request to an attribute that would be fetched from either an authenticated OpenSSO SSOToken or the configured OpenSSO identity data store. The SAML attribute would be placed in the Attribute Statement created by the Security Token Service for a web service provider. The format is SAML_attr_name=OSSO_attr_name where SAML_attr_name is the SAML attribute name in the assertion from an incoming web service request and OSSO_attr_name is the attribute name that is fetched from OpenSSO.
SAML NameID Mapper Plugin: This attribute defines the NameID mapper plug-in class to be used for SAML account mapping.
SAML Attributes Namespace: This attribute defines the name space used to qualify SAML attributes and elements.
Include Memberships: If enabled, this attribute specifies that the principal's membership data must be included in the assertion as a SAML attribute.
Sun Microsystems Releases New Versions of Role Manager and Directory Server Enterprise Edition -- Sun Microsystems, Inc. (NASDAQ: JAVA) today announced new versions of Sun™ Role Manager software and Sun™ Directory Server Enterprise Edition, offering organizations updated tools to intelligently manage their identity portfolio. Customers will benefit from increased business transparency and compliance, simplified access controls, as well as better performance and scalability.
A RESTful web service assumes all components are exposed using the same, uniform application interface. (An interesting article on other requirements of REST can be read here.) From this high-level HTTP accomplishes this uniformity with its methods such as GET and POST. Thus calling a RESTful web service requires the simple construction of a URL.
OpenSSO exposes a number of interfaces that support a REST architecture. These operations are supported out of the box so no special configurations are required. The format of the URL is:
http://OpenSSO-host:OpenSSO-port/opensso/identity/OpenSSO-REST-interface?parameter1=value1¶meter2=value2¶meterN=valueN
The following sections contain information on invoking the available OpenSSO REST interfaces.
The authenticate REST interface opens an HTTP connection to authenticate a user with a POST operation. The following URL defines a username and password that will be authenticated at the OpenSSO root realm - by default, / (Top Level Realm).
http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning
You can also add the optional uri parameter to the URL. The value of this parameter would be one or more of the URL parameters documented in Accessing the OpenSSO Enterprise Authentication Service User Interface with a Login URL. For example, the following URL will authenticate the user to a specific sub realm.
http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning&uri=realm=sub_realm_name
You can define additional parameters. For example, the following URL will authenticate the user to a specific sub realm using the specified authentication chain (ldapService, for example).
http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning&uri=realm=sub_realm_name&service=ldapService
After successful authentication, a token string is returned to represent the authenticated user for other REST operations. Various exceptions might also be thrown such as UserNotFound and InvalidPassword. A generic exception is provided if unable to reach OpenSSO or for other fatal errors.
NOTE: The token string returned is also applied as the value of the subjectid in some OpenSSO REST operations like logout and authorize.
Token Validation
The isTokenValid REST interface validates the token using the POST operation. The following URL defines a tokenid that will be validated by OpenSSO.
http://OpenSSO-host:OpenSSO-port/opensso/identity/isTokenValid?tokenid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=-AT-AAJTSQACMDE=#
The operation returns a value of true or false.
Logout
The logout REST interface validates the token using the POST operation. The following URL defines a tokenid that will be validated by OpenSSO.
http://OpenSSO-host:OpenSSO-port/opensso/identity/logout?subjectid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=-AT-AAJTSQACMDE=#
The operation invalidates the tokenid and logs the user out.
Authorization
The authorize REST interface will verify against created policies that the user is authorized to perform a particular operation (GET or POST) on a particular HTTP resource. The following URL defines a user (subjectid) that wants to POST (action) to the specified resource (uri).
http://OpenSSO-host:OpenSSO-port/opensso/identity/authorize?uri=http://www.sun.com:90&action=POST&subjectid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=@AAJTSQACMDE=#
The operation returns a value of true or false. If the user is not authorized, an exception is thrown. Assuming a policy has been created to allow authenticated users to POST to the defined resource (in this case, http://www.sun.com:90), the above URL would return true.
Logging
The log REST interface will log to the OpenSSO Logging Service. The URL needs to be populated with the following information.
appid defines the tokenid of the user with the necessary permissions to write to the log; for example amadmin.
subjectid defines the tokenid of the user about whom the log record is being written.
logname is the module name of the OpenSSO component invoking the Logging Service; for example, amAuthentication.
message is the data being logged.
An example URL is:
http://OpenSSO-host:OpenSSO-port/opensso/identity/log?appid=AQIC5wM2LY4Sfcz24GvZCdv6ie9dTJBa3Co7Rn2QUjKCDuM=@AAJTSQACMDE=#&subjectid=AQIC5wM2LY4SfcwTCcRKSDXEsiJXt71PDAUmN1bm/draPZI=@AAJTSQACMDE=#&logname=amAuthentication&message=test
Searching Identity Types
The search REST interface will search the configured database for particular identities. The URL needs to be populated with the following information.
filter defines a set of criteria that controls what is returned by the operation.
attributes_name defines one or more LDAP attributes for which to search.
attribute_values_value-of-attributes_name defines the value of the attribute (defined by attributes_name) that is being searched.
admin defines the tokenid of the user with the necessary permissions to search; for example amadmin.
The following URL would return the available agent types; by default string=wsc, string=wsp, and string=SecurityTokenService.
http://OpenSSO-host:OpenSSO-port/opensso/identity/search?filter=*&attributes_names=objecttype&attributes_values_objecttype=agent&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#
This example would return all user entries.
http://OpenSSO-host:OpenSSO-port/opensso/identity/search?filter=*&attributes_names=objectclass&attributes_values_objectclass=person&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#
Display Identity Data
The attributes REST interface will search the configured database for identity information about the defined subjectid. It retrieves roles and common attributes (including first name and last name) and is used by applications to obtain a user's profile for application-controlled authorization. Optionally, the URL can take one or more attribute_names parameters to define which attribute values will be returned; if attribute_names is not defined it would return all the attributes in the profile. This is an example URL that would return the specified user's LDAP profile.
http://OpenSSO-host:OpenSSO-port/opensso/identity/attributes?attributes_names=uid&subjectid=AQIC5wM2LY4Sfcz6eH4abOQ0el7pnDqmOn6nnn1nrcuE8/w=@AAJTSQACMDE=#
The URL might return something like this:
The read REST interface will search the configured database for particular identity information about the LDAP user defined by name. The attributes_names parameter defines one or more LDAP attributes for which to search. This is an example URL that would return the specified user's LDAP profile.
http://OpenSSO-host:OpenSSO-port/opensso/identity/read?name=jning&attributes_names=uid&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#
The URL might return something like this:
The create REST interface will create the defined identity type in the configured data store. The URL needs to be populated with the following information. Note the values for these parameters in the sample URLs below.
identity_name defines a easily-readable name for the identity.
identity_attribute_names defines one or more LDAP attributes to be created for the identity.
identity_attribute_values_value-of-identity_attribute_names defines the value of the attribute (defined by attributes_name) being created.
identity_realm defines the realm in which the identity is created.
identity_type defines the type of identity being created.
admin defines the tokenid of the user with the necessary permissions to create; for example amadmin.
This URL would create a user type. Use the search REST interface to verify its creation.
http://OpenSSO-host:OpenSSO-port/opensso/identity/create?identity_name=rest_user&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=sn&identity_attribute_values_sn=sn_of_rest_user&identity_attribute_names=cn&identity_attribute_values_cn=cn_of_rest_user&identity_realm=/&identity_type=user&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#
The following URL would create a web agent profile for Policy Agent 3.0 types. Use the search REST interface to verify its creation.
http://OpenSSO-host:OpenSSO-port/opensso/identity/create?&identity_name=webagent&identity_realm=/&identity_type=AgentOnly&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=AgentType&identity_attribute_values_AgentType=WebAgent&identity_attribute_names=SERVERURL&identity_attribute_values_SERVERURL=http://web-agent-host:web-agent-port/opensso
The following URL would create a J2EE agent profile for Policy Agent 3.0 types. Use the search REST interface to verify its creation.
http://OpenSSO-host:OpenSSO-port/opensso/identity/create?&identity_name=j2eeagent&identity_realm=/&identity_type=AgentOnly&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=AgentType&identity_attribute_values_AgentType=J2EEAgent&identity_attribute_names=SERVERURL&identity_attribute_values_SERVERURL=http://J2EE-agent-host:J2EE-agent-port/opensso&identity_attribute_names=AGENTURL&identity_attribute_values_AGENTURL=http://OpenSSO-host:OpenSSO-port/opensso
The following URL would create a 2.2 agent profile. Use the search REST interface to verify its creation.
http://OpenSSO-host:OpenSSO-port/opensso/identity/create?identity_name=webagent70&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_realm=/&identity_type=Agent&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#
Updating Identity Data
The update REST interface will update an identity with the information defined in the URL. The following URL would update the user profile with an email address.
http://OpenSSO-host:OpenSSO-port/opensso/identity/update?identity_name=rest_user&identity_attribute_names=mail&identity_attribute_values_mail=restUser@rest-DOT-org&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#
Use the read REST interface to verify the update.
Deleting an Identity Profile
The delete REST interface will remove the identity profile (defined as the value of the identity_name parameter) from the user data store. The following URL would delete the rest_user profile previously created.
http://OpenSSO-host:OpenSSO-port/opensso/identity/delete?identity_name=rest_user&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#&identity_type=user
Use the search REST interface to verify the deletion.
Now check out the not-most-recent-single-but-still-great-video from The Raveonettes: Black / White.
I just finished editing a video on how to federate to Salesforce CRM using OpenSSO in under 5 minutes. It was a lot of fun to make. Like our Google Apps Starter Kit, we'll be launching a Salesforce Starter Kit shortly that walks you through a step-by-step guide on how to do this as well. Basic jist is this solution allows you to reduce sign-ons for your employees and allows them to access Salesforce services using their enterprise credentials rather than their Salesforce credentials. Enjoy!
In a deployment architecture that includes OpenSSO Enterprise 8.0 and Identity Manager 8.1.0.5 (to be released sometime in October) it is possible to configure user password reset based on the password's expiration date, or a help desk administrator's action. In the former use case, when a password is close to expiration, the user data store (which must be an LDAP directory server) can send a warning to the user based on the time configured in the assigned password policy. Upon accessing a resource protected by OpenSSO, the user would be redirected to Identity Manager to change the password. The URL of the protected resource is saved as a value of the goto parameter and the user will be redirected to this location after changing the password.
For the latter use case, if the user allows the password to expire, a help desk administrator can initiate the reset of the expired password by flagging the account and adding a temporary password to the user's profile. The administrator will then communicate the temporary password to the user (by email, for example). Upon logging into OpenSSO with this temporary password, the user will be directed to Identity Manager where the password is reset and the flag is removed.
The procedures documented will enable these use cases. Note that they only support the LDAP authentication module. The following sections contain the configuration procedures.
For this procedure to work it is assumed that a password policy has been configured and assigned to the test user's LDAP profile in the directory server. The password policy should have the following controls related to password expiration set:
Set Password Expiration (LDAP attribute: passwordexp, passwordmaxage)
Set Expiration Warning (LDAP attribute: passwordwarning)
It should also have the following controls set to allow for administrator-driven password reset:
Require Password Change at First Login and After Reset (LDAP attribute: passwordchange, passwordmustchange)
Allow Users to Change Their Passwords (LDAP attribute: pwdallowuserchange)
The passwordPolicySubentry attribute in the test user's LDAP profile should also be defined with the DN of the password policy to denote that the password policy has been assigned. See the documentation for your specific directory server for instructions on how to do these configurations.
Configuring OpenSSO
Only the OpenSSO LDAP authentication module supports the password change controls enforced by most directory servers. The following sections contain OpenSSO configurations.
Click New in the Authentication Chaining section to create a new authentication chain.
Enter a name for the chain and click OK. For this example use idmauth.
On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
Click Back to Authentication.
Select the service just created as the value for Organization Authentication Configuration.
Click LDAP in the Module Instances section.
Customize the LDAP properties to reflect your directory - at minimum:
Primary LDAP Server
DN to Start User Search
DN for Root User Bind
Password for Root User Bind
Password for Root User Bind (confirm)
Save the changes.
Logout from the OpenSSO console.
Note: Following this configuration:
Use /opensso/console to log in to the OpenSSO console (not /opensso/UI/Login) to ensure that the authentication module configured for the OpenSSO administrator is used and not the LDAP module just configured.
Login to the Identity Manager console and expand the OpenSSO resource listing to view the OpenSSO objects. If you receive an error, you may need to reconfigure the OpenSSO adaptor to use a delegated administrator rather than amadmin to connect to OpenSSO. The Identity Manager adaptor for OpenSSO authenticates to OpenSSO using the authentication configuration for the realm which is now different from the configuration for the OpenSSO console. Thus, amadmin will no longer work. See Delegating Administrator Privileges for information on delegating administrative privileges to a group.
To Define Identity Manager URLs as Not Enforced
Login to the OpenSSO console as administrator.
Click the Access Control tab.
Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
Under the agent profile, click the Application tab.
Add the following URIs to the Not Enforced URIs property.
/idm/authutil/
/idm/authutil/*
/idm/authutil/*?*
Click Save.
Logout of OpenSSO.
To Create ChangePassword.jsp
This procedure documents how to create ChangePassword.jsp, a custom JSP for redirecting a user to Identity Manager for password change events. (By default, the user would be directed to the OpenSSO password change page.) ChangePassword.jsp will forward the following information to Identity Manager:
The original URL requested by the user and defined as the value of the goto parameter.
The user identifier defined as the value of the accountId parameter
Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample ChangePassword.jsp.
Modify the Identity Manager URL in the JSP based on your deployment.
Copy ChangePassword.jsp to /web-container-deploy-base/opensso/config/auth/default/ and to /web-container-deploy-base/opensso/config/auth/default_en/.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
Modifying the LDAP Authentication Module XML Service File
This procedure documents how to modify LDAP.xml to use ChangePassword.jsp. There are two options to consider when deciding how to modify LDAP.xml. You can manually change the deployed LDAP.xml file, or you can use the sample LDAP.xml included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.
Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed LDAP.xml page.
Open LDAP.xml in an editor and add the section of code displayed in yellow in admin_pwd_reset_ldap.html on the OpenSSO web site.
Change to the /web-container-deploy-base/opensso/config/auth/default_en/ directory to access the second copy of LDAP.xml and make the same change.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
To Use the Sample LDAP.xml
Change to the opensso/integrations/idm/xml/ directory in the decompressed opensso.zip to access the sample LDAP.xml.
Replace your deployed /web-container-deploy-base/opensso/config/auth/default/LDAP.xml with the sample LDAP.xml in two directories:
If you replace your existing LDAP.xml with the sample LDAP.xml you will lose any custom changes made to the existing LDAP.xml.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.
Modifying the OpenSSO Login Page
This procedure documents how to modify Login.jsp with the necessary code to save the URL value of the goto parameter in the HTTP request. This saved URL is required by the ChangePassword.jsp. The saved URL (which is the original location desired by the user) will be passed to Identity Manager and used to redirect the user after unlocking has been completed.
There are two options to consider when deciding how to embed code into the OpenSSO Login.jsp. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.
Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
Open Login.jsp in an editor and add the two (2) sections of code displayed in yellow in admin_pwd_reset_login.html on the OpenSSO web site.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp
Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture. You can search for the string /idm to locate the URLs.
Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp. If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
You will lose any custom changes made to the existing Login.jsp.
You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.
Testing The Configurations
Perform the tests in the order in which they are described to understand and verify the behavior for each stage of this use case.
A. Testing Password Warning Expiration
Perform the following actions after the time the password expiration warning, as defined in the password policy, would take effect.
Access a URL protected by OpenSSO. The OpenSSO login page is displayed.
Enter the test user name and password. You will be redirected to Identity Manager to change your password. Note the following about the Identity Manager URL:
The URL is the one configured in ChangePassword.jsp.
The user will be forwarded to the value of the goto parameter after the password has been successfully changed.
The value of the accountId parameter determines the account for which the password needs to be changed. Identity Manager will make the changes to the password on both Identity Manager and OpenSSO.
B. Testing Password Expiration
Perform the following actions after the time the password should have expired, as defined in the password policy.
Access a URL protected by OpenSSO. The OpenSSO login page is displayed.
Enter the test user name and password. An error page is displayed informing the test user that the password has expired. The user will be instructed to have the administrator reset the password.
C. Testing Administrator Password Reset
Refer to your directory server documentation to enable audit and logging. Monitor the directory server audit log as you finish the test.
Login as the directory administrator and change the password for a test user. This simulates the password reset by a help desk administrator.
Verify that the user's userPassword attribute was modified and the pwdreset was set to TRUE using the audit log. The pwdreset attribute will force the user to change the password at the next login. The audit log might resemble this sample.
Access the Identity Manager user URL. You will be redirected to OpenSSO for login.
Enter the test user name and password. You will be redirected to Identity Manager to change your password. Note the following about the Identity Manager URL:
The URL is the one configured in ChangePassword.jsp.
The user will be forwarded to the value of the goto parameter after the password has been successfully changed.
The value of the accountId parameter determines the account for which the password needs to be changed. Identity Manager will make the changes to the password on both Identity Manager and OpenSSO.
For those fans of The Real Housewives of Atlanta, here's a fan-made video of Kim Zolciak's (Don't Be) Tardy for the Party. (I added the parentheticals to make it seem official.) Kandi Burress produced a dance floor smash for the woman who can not sing! Who knew?
User account lockout in OpenSSO can happen in either of the following ways:
Memory account lockout occurs when the user has exceeded the allowed number of failed attempts to log in as configured in the password policy. The user may remain locked out for a set period of time and can only reset the password after that period has passed. The locked state of the user account is maintained in memory and no information is written to the user's LDAP profile.
Physical account lockout occurs when the status of a specified LDAP attribute in the user’s profile is explicitly changed to Inactive, either by an administrator or as a result of some automated processes. (The specified LDAP attribute is defined as the value of the Lockout Attribute Name attribute in the Core authentication module.) By default it is inetuserstatus.
When a user's account is locked, it is possible to allow the user to unlock the account without intervention from an administrator. The procedures documented will enable this for a deployment with OpenSSO Enterprise 8.0 and Identity Manager 8.1.0.5 (to be released sometime in October). Note that memory account lockout in OpenSSO must be disabled using the OpenSSO console as the account lockout controls in the user data store will be used. Using this feature in a deployment with OpenSSO and Identity Manager only supports the LDAP authentication module. The following sections contain the configuration procedures.
For this procedure to work it is assumed that a password policy has been configured and assigned to the test user's LDAP profile in the directory server. The password policy should have the following controls set:
The passwordPolicySubentry attribute in the test user's LDAP profile should also be defined with the DN of the password policy to denote that the password policy has been assigned. See the documentation for your specific directory for instructions on how to do these configurations.
Configuring OpenSSO
The OpenSSO LDAP authentication module supports the account lockout controls enforced by most directory servers. The following sections contain OpenSSO configurations.
Click New in the Authentication Chaining section to create a new authentication chain.
Enter a name for the chain and click OK. For this example use idmauth.
On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
Click Back to Authentication.
Select the service just created as the value for Organization Authentication Configuration.
Save the changes.
Logout from the OpenSSO console.
Note: Following this configuration, use /opensso/console to log in to the OpenSSO console (not /opensso/UI/Login) to ensure that the authentication module configured for the OpenSSO administrator is used and not the LDAP module just configured.
To Define Identity Manager URLs as Not Enforced
Login to the OpenSSO console as administrator.
Click the Access Control tab.
Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
Under the agent profile, click the Application tab.
Add the following URIs to the Not Enforced URIs property.
/idm/authutil/
/idm/authutil/*
/idm/authutil/*?*
Click Save.
Logout of OpenSSO.
Modifying the OpenSSO Login Page
This procedure documents how to modify Login.jsp with the necessary code for this use case. The code will save the value of the goto parameter in the HTTP request. This saved URL is required by the user_inactive.jsp created in the next procedure. The saved URL (which is the original location desired by the user) will be passed to Identity Manager and used to redirect the user after unlocking has been completed.
There are two options to consider when deciding how to embed code into the OpenSSO Login.jsp. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually-exclusive so choose only one of these procedures.
Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
Open Login.jsp in an editor and add the two (2) sections of code displayed in yellow in account_unlock_login.html on the OpenSSO web site.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp
Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture. You can search for the string /idm to locate the URLs.
Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp. If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
You will lose any custom changes made to the existing Login.jsp.
You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.
Modifying the OpenSSO Account Lockout Message Page
This procedure documents how to modify user_inactive.jsp, the JSP that notifies the user that the account is locked. You will modify the page to include a redirect to an Identity Manager page that will enable the user to unlock the account. user_inactive.jsp will forward the following information to Identity Manager:
The original URL requested by the user and defined as the value of the goto parameter.
The user identifier defined as the value of the accountId parameter
There are two options to consider when deciding how to embed code into the OpenSSO user_inactive.jsp. You can manually change the deployed user_inactive.jsp file, or you can use the sample user_inactive.jsp included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.
To Manually Modify the Account Lockout Message Page
Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed user_inactive.jsp page.
Open user_inactive.jsp in an editor and add the two (2) sections of code displayed in yellow in account_unlock_inactive.html on the OpenSSO web site. Embedded in the JSP, you will see the URL to the Identity Manager page that allows the account unlock. You should modify this URL as per your deployment.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
Note: The Identity Manager URL used in the sample refers to anonResetPassword.jsp. You might, however, direct the user to questionLogin.jsp, the forgotten password page because if a user has accidentally locked an account it may be because of a forgotten password.
To Use the Sample Account Lockout Message Page
Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample user_inactive.jsp.
Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture. You can search for the string /idm to locate the URLs.
Replace your deployed /web-container-deploy-base/opensso/config/auth/default/user_inactive.jsp with the sample user_inactive.jsp. If you replace your existing user_inactive.jsp with the sample user_inactive.jsp the following will occur.
You will lose any custom changes made to the existing Login.jsp.
You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.
Testing The Configurations
The following procedures document testing these configurations for memory account lockout and physical account lockout.
Configure the password policy and assign the policy to the test user. This is done using the user data store.
Access a resource protected by OpenSSO to get redirected to the login page.
Login to OpenSSO using an incorrect password. Do this consecutively until the account gets locked and the error page is displayed. This will be dependent on the number of attempts configured in the password policy.
Click the hyperlink on the page. You will be redirected to an Identity Manager page on which you will be required to change your password. Note that the URL is the one configured in the user_inactive.jsp.
Change your password. Identity Manager determines the account from the accountID parameter and will change the password on both OpenSSO and Identity Manager. After a successful modification, the user will be redirected to the original URL defined in the goto parameter.
To Test Physical Account Lockout
Set the value of the inetuserstatus attribute in the test user's profile in the user data store to Inactive.
Access a resource protected by OpenSSO to get redirected to the login page.
Login to OpenSSO. An error page will be displayed informing you that the account has been locked.
Click the hyperlink on the page. You will be redirected to an Identity Manager page on which you will be required to change your password. Note that the URL is the one configured in the user_inactive.jsp.
Change your password. Identity Manager determines the account from the accountID parameter and will change the password on both OpenSSO and Identity Manager. After a successful modification, the user will be redirected to the original URL defined in the goto parameter.
And now here are some girls doing it for themselfes: Cyndi Lauper, Ann Wilson, Nancy Wilson, Wynona Judd, Amy Grant and Destiny's Child (Beyonce, Kelly Rowland and Michelle Williams) performing a live version of Hey Now (Girls Just Wanna Have Fun).
Another new error Product deployment failed in solaris with error some jre lib exception Googling said I had to increase the number of processes in os level in /etc/system But even vi failed with "no more processes" So had to reboot and issue gone!!
Here's a look at the procedures to enable auto provisioning of OpenSSO Enterprise 8.0 with a user account created on-the-fly by a user accessing Identity Manager 8.1.0.5 (to be released sometime in October) for the first time. (They are being integrated into the OpenSSO Integration Guide as I type.) The configurations will allow an end user to create a personal account on Identity Manager and, following creation, this account data will be provisioned to OpenSSO automatically. The user account created would be the most basic account with the minimum privileges available.
In the Identity Manager WAR, /idm is the base context of the deployment. The architecture of this use case assumes there is a policy agent protecting Identity Manager.
To configure OpenSSO, you will define Identity Manager URIs as not enforced for the policy agent. You will also need to modify the OpenSSO login page so that it will display a Register User button.
To Define Identity Manager URLs as Not Enforced
Login to the OpenSSO console as administrator.
Click the Access Control tab.
Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
Under the agent profile, click the Application tab.
Add the following URIs to the Not Enforced URIs property.
/idm/authutil/
/idm/authutil/*
/idm/authutil/*?*
Click Save.
Logout of OpenSSO.
Modifying the OpenSSO Login Page
There are two options to consider when deciding how to display a Register User button on the OpenSSO login page. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually-exclusive so choose only one of these procedures.
Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
Open Login.jsp in an editor and add the five (5) sections of code displayed in yellow in self_registration_login.html on the OpenSSO web site.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp
Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture. You can search for the string /idm to locate the URLs.
Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp. If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
You will lose any custom changes made to the existing Login.jsp.
You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up. For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.
Configuring Identity Manager
To configure Identity Manager, you will change the registration work flow. There are two options to consider when deciding how to change the registration work flow. You can use the Identity Manager plug-in for NetBeans IDE or, use the Identity Manager Debug Pages. They are mutually-exclusive so choose only one of these procedures.
Create (or open) an Identity Manager Project in NetBeans. There are two types of projects: integrated and remote. This procedure applies in either case. Use the online help available in NetBeans to create the Identity Manager project if necessary. The Identity Manager IDE website also has some pointers.
From the NetBeans Project Window, right-click on the Custom Identity Manager Objects Node and select IDM > Open Object.
In the Open Object dialog box, enter the object name End User Anonymous Enrollment and select OK.
Right-click on the file in the Project Window and select IDM > Clone Object(s) to clone the object for safe keeping.
Name the new object End User Anonymous Enrollment Orig.
Click on the tab in the Editor window containing the file End User Anonymous Enrollment work flow. This will put the file in focus.
Expand the tree in the Navigator Window to locate the Activity Assimilate User View.
Add the OpenSSO resource to the map of options for the "assimilate" invocation. Refer to self_registration_idm_anon_enroll.html on OpenSSO for the changes to be made to the object. The name of the OpenSSO resource (OpenSSO in self_registration_idm_anon_enroll.html) is the name assigned when the resource was created. To verify the name, navigate to the "Resources | List Resources" tab in the Identity Manager administration console and expand the "Sun Access Manager Realm" branch.
Save the changes.
Right-click on the file and select IDM > Upload Object(s) to upload the file.
To Use the Identity Manager Debug Pages
Login to the Identity Manager console as administrator.
Go to the debug URL at protocol://IDM-host-machine:port/idm/debug.
Select the object "Task Definition" in the list next to the "List Objects" button.
Click on the "List Objects" button.
Search for the object "End User Anonymous Enrollment" and click on its "edit" hyperlink. You might first export the existing definition and save it.
Add the OpenSSO resource to the Activity "Assimilate User View". Refer to self_registration_idm_anon_enroll.html on OpenSSO for the changes to be made to the object. The name of the OpenSSO resource (OpenSSO in self_registration_idm_anon_enroll.html) is the name assigned when the resource was created. To verify the name, navigate to the "Resources | List Resources" tab in the Identity Manager administration console and expand the "Sun Access Manager Realm" branch.
Logout of the console.
Testing The Configurations
Perform the tests in the order in which they are described to understand and verify the behavior for each stage of this use case.
A. User Self-Registration
Go to the OpenSSO login URL at protocol://OSSO-host-machine:port/opensso/UI/Login.
Click the "Register User" button to register a test user.
Go through the registration process and click the "Register" button. A message is displayed signifying that the registration request is being processed.
B. Approval Of New User Account
Login to the Identity Manager console as an administrator. The "Create User" pending task is displayed as "Create User ".
Navigate to the "Work Items | Approvals" tab.
Select the provisioning task for the new user-id and click the "Approve" button.
Confirm the approval.
Logout of the Identity Manager console.
C. Verify Provisioning Of New User Account
Login to the OpenSSO console as administrator.
Navigate to the "Access Control | realm | Subjects" tab. The approved user is displayed indicating that the profile was successfully registered and provisioned.
D. Verify Activation Of New User Account
Go to the OpenSSO login URL at protocol://OSSO-host-machine:port/opensso/UI/Login and login as the new user. A successful login indicates that the new user is active.
Logout of OpenSSO.
Now on to another look, Just One Look from Linda Ronstadt.
I wanted to update you on the news last week about Pat Patterson (aka SuperPat) moving on from Sun and our search for a new community lead.
As you all now know, Pat has moved on from Sun and thus has stepped down as the OpenSSO community lead. I want to wish Pat the best of luck in his future endeavors. He is not only an icon among the OpenSSO world, but he is also a great friend. I jokingly told Pat on his last day that he is "now dead to me," but the truth is I will miss him dearly and look forward to pestering him lots in the future.
That said, I am very happy to announce that our new OpenSSO community lead is Hubert Le Van Gong. Hubert has a long history with OpenSSO. He is an identity architect at Sun with strong expertise in IdM protocols as well as RESTful web services. He started working with OpenSSO in the context of interoperability with the Microsoft-backed web services stack. True to Sun's tradition of eating its own dog food, he then helped deploy OpenSSO and its OpenID extension as an Identity Provider for Sun employees. More recently Hubert has been working on new OpenSSO extensions like OAuth and OpenID 2.0. Check out Hubert's blog to read about OpenSSO community activity and feel free to ping him via IRC. His IRC handle is hubertlvg.
In addition to Hubert, you can always contact me directly at daniel.raskin@sun.com or Jamie Nelson, the Director of OpenSSO Engineering, at jamie.nelson@sun.com. We are also on IRC and our handles are draskin and jamiefnelson, respectively.
Please join me in welcoming Hubert to his new role and start pinging away with questions!
This entry describe how to configure single logout between Identity Manager 8.1.0.5 (to be released sometime in October) and OpenSSO Enterprise 8.0. In the Identity Manager WAR, /idm is the base context of the deployment and thus the admnistrator area; /idm/user is the user area. You should be able to do the following:
If logged out of the administration area, the person should be redirected to the same upon re-login.
If logged out of the user area, the person should be redirected to the same upon re-login.
A policy agent protecting Identity Manager protects both areas and the agent's OpenSSO profile needs to be configured to allow for the separate functions. This first procedure illustrates how to configure OpenSSO.
Log in to the OpenSSO administration console as the administrator.
Click the Access Control tab.
Click the appropriate realm name and navigate to the agent profile for the policy agent that protects Identity Manager.
Under the agent profile, click the Application tab.
Click Logout Processing.
Add the following map keys and values to the Application Logout URI property:
idm=/idm/logout.jsp
idm/user=/idm/user/userLogout.jsp
Add the following map and key values to the Logout Entry URI property:
idm=/idm
idm/user=/idm/user
Click Save.
Log out of OpenSSO.
These properties are hot-swappable in that they do not require a restart of OpenSSO to take effect. This second procedure illustrates how to test the configuration.
Log into Identity Manager.
In the Identity Manager application window, click Logout IDM.
This should log you out of both Identity Manager and OpenSSO and then redirect you back to the OpenSSO login page.
Log in to OpenSSO. You should be redirected to the specific Identity Manager administrator or user profile.
I watched the movie version of the musical Hair last night and remembered what a wonderful, vibrant motion picture that it is. Here is Good Morning Starshine as sung by Beverly D'Angelo who, for Entourage fans, played Mandy Moore's agent.
If your OpenSSO deployment architecture includes a reverse proxy server, you have the option of protecting the content servers by installing a policy agent on the proxy itself, or installing multiple policy agents on the content servers behind the reverse proxy server. The choice is dependent on the relative uniformity or variability of the hosted/protected content and the access-denied URLs.
NOTE: A reverse proxy server or a load balancer with a reverse proxy feature is usually installed between the outer firewall and the inner firewall - in the demilitarized zone (DMZ) between the internet and the secure intranet.
Using a Single Agent
When there is a uniformity in the configuration of the content servers in the back-end (including access denied URLs, application logout URLs, profile, session and response attributes, and the web container type), a single policy agent for the reverse proxy server would be the efficient way of protecting the content. The following diagram illustrates this.
Regardless of the number of content servers being fronted by the reverse proxy, only one agent is installed on the reverse proxy machine. The footprint of this configuration is less cost (fewer agents to maintain) and less memory (a single agent requires less memory to cache). With one agent no communication will occur between the content servers and the OpenSSO server. The policy agent will have back channel communications with the OpenSSO load balancer to update cache entries, perform session validation, and make policy requests but, since the agent is installed on the reverse proxy server and not on the content servers, only the reverse proxy server would communicate with the OpenSSO load balancer. This effectively reduces the number of communication channels which would result in fewer firewall rules, tighter control over server-to-server communications, and a higher level of security.
Using Multiple Agents
When a number of content servers use different types of web containers or each content server has different access denied URLs, agent profiles, session and response attributes, and application logout URLs, the only choice is to install multiple policy agents. Each agent will have its own customized agent profile.
Unlike in the case of the single reverse proxy server policy agent where the same session identifier is used to access many applications protected by the agent, multiple policy agents do not use the same session identifier (when the agents are configured in cookie hijacking prevention mode). With multiple agents, it is now easy to customize agent properties per content server; for example, customize profile attributes to be fetched, session attributes to be fetched, response attributes to be added to the header, URL of the access denied page, customized application error pages, and application logout URLs. (By customizing each application's logout URL, it is possible to perform cleanup tasks (destroying the user's session or resetting cookies) per application.
See the following links for more information.
As Kohsuke mentions, this has a number of advantages - every AD admin knows the domain name, while many would likely have to go look up an individual host name, not to mention the LDAP port number. Since we use the domain name to look up an individual AD controller via DNS, it also means that the admin doesn't need to update OpenSSO's configuration as AD controllers come and go - OpenSSO will always get a valid host name from DNS.
So, when configuring OpenSSO Express 8, you can now just specify the AD domain name. As improvements go, this one is pretty small, but, as I think everyone agrees, the cumulative effect of all these little improvements in OpenSSO over the past two or three years has been HUGE...
A couple of days forward to the announcement about the availability of OpenSSO Express 8, I met up with the folks in the photograph below at our Learning Center in Bangalore for a five day session on OpenSSO deployment. Thanks to David Goldsmith for developing a near perfect OpenSSO Deployment Labs, employing the powerful features of Solaris 10 OS like Solaris Containers and ZFS, giving the audience of this program an experience close to a real time OpenSSO deployment.
Since the course used a number of software components like Glassfish, WebServer, 'OpenDS', Directory Server EE and of course OpenSSO, I requested all participants to help me do a quick review of the entire course on the last day by doing a teach back. Thanks to each of them for doing a good job reviewing the topics well, helping each other gain considerably good clarity on the overall contents of the course.
For me, the bygone week was nothing less than immensely satisfying.
This month, Rick's written another article, this time with Qingwen Cheng and Mrudul Uchil of Sun's OpenSSO engineering team. Enabling IP/Resource/Environment Based Authentication With OpenSSO is a three-part series explaining how this functionality, new in OpenSSO Express Build 8, replaces the pre-existing Gateway servlet to provide a flexible mechanism for including contextual information in the authentication process.
There have been a number of OpenSSO policy agent releases over the past few weeks, including agents for Apache 2.2 and IIS 7. The OpenSSO Policy Agents 3.0 Roadmap is the place to stay up to date.
Markmail is kind of cool as it archives emails. I was looking at it today to see OpenSSO’s archive and found this.
Gee, I have sent over 9000 emails to OpenSSO’s email aliases for the past 4 years.
That’s 2381 emails per year. About 9 emails per day (excluding weekends). So, 1 email per hour! (8-9 hours work day).
CTI, which stands for Community Translation Interface, is a tool we used already to get some translations for OpenSSO, and a tool we plan to use more.
CTI just launched a survey to gather feedbacks from users, from a general point of view: what you like, don't like, what you want to see, etc... It is a 14 questions survey, ~10mins, straightforward, simple. 20 Globalization T-shirts are to be wan !
OpenSSO Express 8, an interim release of Sun OpenSSO Enterprise is now available for download. Check out Sidharth's blog to have a quick look at the new and exciting features in OpenSSO Express 8 (Yippee, support for MySQL as User Data Store). Should you wish to have a detailed study on the OpenSSO Express 8, click here.
OpenSSO Express 8, an early access version of next release of Sun's Web Access Management solution (and that's fully supported and indemnified by Sun Microsystems for customers), is now available for download. You can download OpenSSO Express 8 by visiting, https://opensso.dev.java.net/public/use/index.html.
OpenSSO Express 8 introduces number of exciting new features such as:
- One Time Password based Strong Authentication - Federated SSO for Dot Net applications using DotNET Fedlet. - Support for MySQL as an user data store. - Entitlement Service - A new look Beta Administration Console that allows to administer Entitlement Service and makes available easy to use workflows for Federation and Web Services Security. - Common task based workflow for federated SSO setup with Salesforce.COM. And more...
A list of all the new features and enhancements in OpenSSO Express 8 is available as part of Release Notes, at - http://wikis.sun.com/display/OpenSSO/OpenSSO+Express+8+Release+Notes#OpenSSOExpress8ReleaseNotes-WSS
Detailed documentation on OpenSSO Express 8 and the features, is available on OpenSSO Documentation wiki, at - http://wikis.sun.com/display/OpenSSO/Sun+OpenSSO+Documentation
Congratulations to all OpenSSO community members and special thanks to those that contributed towards OpenSSO Express 8!
It's worth noting that OpenSSO Express Builds are supported builds, released on an approximately 3 month cycle between Enterprise builds. Customers simply buy support for OpenSSO and then choose which build to deploy; the main difference between the two is that we release hot patches and service packs for the Enterprise build, while fixes in the Express build are rolled into the next Express build (no hot patches or service packs). In this way, customers who are keen to deploy the very latest OpenSSO features with support can do so without having to wait up to 12 months for the next Enterprise release. More on this release in the OpenSSO Express 8 release notes; more on the Express build concept in the OpenSSO Express FAQ.
Congratulations to all on the release of OpenSSO Express 8, an early access version of Sun OpenSSO Enterprise that is fully supported and indemnified by Sun Microsystems for customers. The new ZIP archive is available for download on opensso.dev.java.net.
OpenSSO Express 8 introduces:
One Time Password Authentication
A new Resource Authentication Type
Federated single sign-on for .Net applications using the .NET Fedlet
Support for MySQL as a user data store
The new Entitlements Service
A new monitoring framework built using the Java Dynamic Management Kit (JDMK)
A new Administration Console (in beta) that allows authorization administration with the new Entitlements Service and new work flows for configuring federation and web services security
A new work flow for setting up federated single sign-on with Salesforce.COM
A list of all the new features and enhancements in OpenSSO Express 8 is available as part of Release Notes. Detailed documentation on the new features is available on the OpenSSO Documentation wiki.
And here's an incredible (and incredibly old) performance of Bette Midler singing Bob Dylan's I Shall Be Released.
Arrrr, me mateys! 
Critics of the RBAC model argue that RBAC is static and believe that taking an RBAC-only approach will lead to an excessive number of roles. They argue that policy decisions will need to leverage Roles plus attributes embedded within your application infrastructure. 
As we refine entitlement enforcement in OpenSSO (our Beta was made available in September 2009) we are looking at this from both perspectives and expecting real implementations to require a hybrid solution that is dynamic and can take in to consideration both roles and attributes. Our solution consumes roles, allows applications to push attributes to OpenSSO for policy evaluation, and allows OpenSSO to pull attributes for policy evaluation. In fact, OpenSSO also supports policy referrals or partial policy referrals to help make an "accept" or "deny" decision. 
