Main | Next page »
Thursday Nov 05, 2009

Harden OpenSSO By Disabling ssoadm.jsp

Notwithstanding that it is still a secret, we've just added a property that allows you to disable the ssoadm.jsp to harden your system and reduce attack vectors. The property is ssoadm.disabled and can be added with a value of true to the Advanced properties.

  1. Log into the OpenSSO console as administrator.
  2. Click the Configuration tab.
  3. Click the Servers and Sites tab.
  4. Click the Server name in the Servers table.
  5. Click the Advanced tab.
  6. Click Add in the Advanced Properties table.
  7. Enter ssoadm.disabled as the Property Name and true as the Property Value.
  8. Click Save.

You can also add this property as a default setting for future server configurations by clicking the Default Server Settings button under the Servers and Sites tab.

And now here's the only song that I know of that uses the word harden. The video is a live performance of Quarterflash singing (and playing saxophone on) Harden My Heart.

Posted at 04:52PM Nov 05, 2009 by Michael Teger in Sun  |  Comments[0]

Monday Nov 02, 2009

Switch On Switch Off OpenSSO SAMLv2 Services

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.

  1. Log into the OpenSSO console as administrator.
  2. Click the Federation tab.
  3. Click the name of the entity provider for which you want switch off a particular SAMLv2 Service.
  4. Click the Services tab.
  5. Remove the appropriate endpoint.
  6. Click Save.
You can also use the ssoadm command line interface.
  1. Use ssoadm export-entity to export the extended metadata.
  2. Modify the exported extended metadata.
  3. Use ssoadm delete-entity to delete the original extended metadata.
  4. 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

Posted at 01:30PM Nov 02, 2009 by Michael Teger in Sun  |  Comments[0]

Tuesday Oct 20, 2009

Someone Needs a ヴァケイション

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?

Posted at 09:03AM Oct 20, 2009 by Michael Teger in Sun  |  Comments[2]

Tuesday Oct 13, 2009

Cool Changes to the OpenSSO Console

Some new attributes have been added to the OpenSSO Administration Console and are available now in the nightly builds.

  1. 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.

  2. 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).

  3. 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.

Now here's Cool Change from Little River Band.

Posted at 11:44AM Oct 13, 2009 by Michael Teger in Sun  |  Comments[2]

Friday Oct 09, 2009

A Happy Working Song for the Technical Writer

My manager forwarded to the team this article on CNNMoney.com that ranks the best jobs in America. I was surprised to read that Technical Writer was only ranked at number 28. From my (admittedly skewed) perspective it should top the list.

Technical writing is a challenging job that offers the opportunity to educate yourself and others while getting paid. Over the years I've worked at some amazing companies, and with some incredibly talented people. And I get to write! And I get to create diagrams and illustrations! I might not have the paparazzi on my tail but can Nicole Richie explain the difference between symmetric and asymmetric key encryption? I think not.

So if you're a teen (or a parent of a teen) who is trying to decide what to do with yourself as an adult, read up on technical writing. It's a way of making a living that makes me want to sing a daily Happy Working Song (as embodied by Amy Adams in Enchanted).

Posted at 11:12AM Oct 09, 2009 by Michael Teger in Personal  |  Comments[0]

Thursday Oct 08, 2009

The OpenSSO REST Interfaces in Black / White

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&parameter2=value2&parameterN=valueN

The following sections contain information on invoking the available OpenSSO REST interfaces.

Authentication

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: 
userdetails.token.id=AQIC5wM2LY4Sfcz6eH4abOQ0el7pnDqmOn6nnn1nrcuE8/w=@AAJTSQACMDE=#
userdetails.attribute.name=sn
userdetails.attribute.value=jning
userdetails.attribute.name=cn
userdetails.attribute.value=jning
userdetails.attribute.name=objectclass
userdetails.attribute.value=sunFederationManagerDataStore
userdetails.attribute.value=top
userdetails.attribute.value=iplanet-am-managed-person
userdetails.attribute.value=iplanet-am-user-service
userdetails.attribute.value=organizationalperson
userdetails.attribute.value=inetadmin
userdetails.attribute.value=iPlanetPreferences
userdetails.attribute.value=person
userdetails.attribute.value=inetuser
userdetails.attribute.value=sunAMAuthAccountLockout
userdetails.attribute.value=sunIdentityServerLibertyPPService
userdetails.attribute.value=inetorgperson
userdetails.attribute.value=sunFMSAML2NameIdentifier
userdetails.attribute.name=userpassword
userdetails.attribute.value={SSHA}XhiE0RMwO/D7SSQ5fYLrTlFjmbHmYbQkIU43FA==
userdetails.attribute.name=uid
userdetails.attribute.value=jning
userdetails.attribute.name=givenname
userdetails.attribute.value=jning
userdetails.attribute.name=inetuserstatus
userdetails.attribute.value=Active

Display Particular Identity Data

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: 
identitydetails.name=jning
identitydetails.type=user
identitydetails.realm=dc=opensso,dc=java,dc=net
identitydetails.attribute=
identitydetails.attribute.name=uid
identitydetails.attribute.value=jning

Creating Identity Types

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.

Posted at 02:47PM Oct 08, 2009 by Michael Teger in Sun  |  Comments[7]

Monday Oct 05, 2009

Larry Ellison and Ed Zander Together Again for the First Time

Check out this interview of Larry Ellison (future CEO of Sun assets if all goes as planned with the EU) by Ed Zander (former President of Sun Microsystems). Some interesting tidbits on our future.

Posted at 12:00AM Oct 05, 2009 by Michael Teger in Sun  |  Comments[0]

Friday Oct 02, 2009

A 2001 Holiday Party with IMS

I found these pictures of a holiday party the future OpenSSO team had on December 17, 2001. I believe at the time we were called Identity Management Services (IMS). Some are long gone, some are still here, and even then Ajay was leading the games. No music in this entry - just memories.

Posted at 12:00AM Oct 02, 2009 by Michael Teger in Sun  |  Comments[0]

Tuesday Sep 29, 2009

Don't Be Tardy: Configure Password Expiration with OpenSSO and Identity Manager

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.

Configuring the LDAP Directory Server

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)
  • Warning Duration (LDAP attribute: passwordExpireWithoutWarning)
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.

To Enable LDAP Authentication

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name.
  4. Click the Authentication tab.
  5. Click New in the Authentication Chaining section to create a new authentication chain.
  6. Enter a name for the chain and click OK.
    For this example use idmauth.
  7. On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
  8. Click Back to Authentication.
  9. Select the service just created as the value for Organization Authentication Configuration.
  10. Click LDAP in the Module Instances section.
  11. 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)
  12. Save the changes.
  13. 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

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
  4. Under the agent profile, click the Application tab.
  5. Add the following URIs to the Not Enforced URIs property.
    • /idm/authutil/
    • /idm/authutil/*
    • /idm/authutil/*?*
  6. Click Save.
  7. 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

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample ChangePassword.jsp.
  2. Modify the Identity Manager URL in the JSP based on your deployment.
  3. Copy ChangePassword.jsp to /web-container-deploy-base/opensso/config/auth/default/ and to /web-container-deploy-base/opensso/config/auth/default_en/.
  4. 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/.
  5. 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.
To Manually Modify a Deployed LDAP.xml
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed LDAP.xml page.
  2. 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.
  3. 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.
  4. 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/.
  5. Restart the OpenSSO web container after making the changes.
To Use the Sample LDAP.xml

  1. Change to the opensso/integrations/idm/xml/ directory in the decompressed opensso.zip to access the sample LDAP.xml.
  2. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/LDAP.xml with the sample LDAP.xml in two directories:
    • /web-container-deploy-base/opensso/config/auth/default/
    • /web-container-deploy-base/opensso/config/auth/default_en/
    If you replace your existing LDAP.xml with the sample LDAP.xml you will lose any custom changes made to the existing LDAP.xml.
  3. 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/.
  4. 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.
To Manually Modify a Deployed Login.jsp
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
  2. 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.
  3. 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/.
  4. Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
  2. 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.
  3. 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.
  4. 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/.
  5. 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.
  1. Access a URL protected by OpenSSO.
    The OpenSSO login page is displayed.
  2. 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.
  1. Access a URL protected by OpenSSO.
    The OpenSSO login page is displayed.
  2. 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

  1. Refer to your directory server documentation to enable audit and logging.
    Monitor the directory server audit log as you finish the test.
  2. Login as the directory administrator and change the password for a test user.
    This simulates the password reset by a help desk administrator.
  3. 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. 
    time: 20090713074720
dn: uid=idmuser1,dc=sun,dc=com
changetype: modify
replace: userPassword
userPassword: {SSHA}4Bgy/HF9SGN9nnS4Ii6/KJj9ktFdAxQUIDvwVQ==
-
replace: modifiersname
modifiersname: cn=admin,cn=administrators,cn=dscc
-
replace: modifytimestamp
modifytimestamp: 20090713144720Z
-
replace: passwordexpirationtime
passwordexpirationtime: 19700101000000Z
-
replace: pwdreset
pwdreset: TRUE
  4. Access the Identity Manager user URL.
    You will be redirected to OpenSSO for login.
  5. 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?

Posted at 08:25AM Sep 29, 2009 by Michael Teger in Sun  |  Comments[0]

Monday Sep 28, 2009

Configuring Self Unlock After Account Lockout Using OpenSSO and Identity Manager is Fun

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.

Configuring the LDAP Directory Server

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:
  • Enable Account Lockout (LDAP attribute: passwordLockout)
  • Failures Before Lockout (LDAP attribute: passwordMaxFailure)
  • Failure Count Reset (LDAP attribute: passwordResetFailureCount)
  • Set Limit on Lockout Duration (LDAP attribute: passwordUnlock)
  • Lockout Duration (LDAP attribute: passwordLockoutDuration)
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.

To Enable LDAP Authentication

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name.
  4. Click the Authentication tab.
  5. Click New in the Authentication Chaining section to create a new authentication chain.
  6. Enter a name for the chain and click OK.
    For this example use idmauth.
  7. On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
  8. Click Back to Authentication.
  9. Select the service just created as the value for Organization Authentication Configuration.
  10. Save the changes.
  11. 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

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
  4. Under the agent profile, click the Application tab.
  5. Add the following URIs to the Not Enforced URIs property.
    • /idm/authutil/
    • /idm/authutil/*
    • /idm/authutil/*?*
  6. Click Save.
  7. 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.
To Manually Modify a Deployed Login.jsp
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
  2. 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.
  3. 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/.
  4. Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
  2. 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.
  3. 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.
  4. 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/.
  5. 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
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed user_inactive.jsp page.
  2. 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.
  3. 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/.
  4. 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

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample user_inactive.jsp.
  2. 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.
  3. 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.
  4. 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/.
  5. 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.
To Test Memory Account Lockout
  1. Configure the password policy and assign the policy to the test user.
    This is done using the user data store.
  2. Access a resource protected by OpenSSO to get redirected to the login page.
  3. 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.
  4. 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.
  5. 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
  1. Set the value of the inetuserstatus attribute in the test user's profile in the user data store to Inactive.
  2. Access a resource protected by OpenSSO to get redirected to the login page.
  3. Login to OpenSSO.
    An error page will be displayed informing you that the account has been locked.
  4. 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.
  5. 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).

Posted at 12:00AM Sep 28, 2009 by Michael Teger in Sun  |  Comments[5]

Wednesday Sep 23, 2009

A Look at Enabling Automatic OpenSSO Provisioning After Identity Manager Self-registration

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.

Configuring OpenSSO

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

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
  4. Under the agent profile, click the Application tab.
  5. Add the following URIs to the Not Enforced URIs property.
    • /idm/authutil/
    • /idm/authutil/*
    • /idm/authutil/*?*
  6. Click Save.
  7. 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.
To Manually Modify a Deployed Login.jsp
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
  2. 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.
  3. 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/.
  4. Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
  2. 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.
  3. 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.
  4. 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/.
  5. 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.

To Change the Registration Work Flow Using Netbeans IDE

This procedure assumes that you have downloaded and installed NetBeans IDE and downloaded and installed the Identity Manager Plug-in for NetBeans.
  1. 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.
  2. From the NetBeans Project Window, right-click on the Custom Identity Manager Objects Node and select IDM > Open Object.
  3. In the Open Object dialog box, enter the object name End User Anonymous Enrollment and select OK.
  4. Right-click on the file in the Project Window and select IDM > Clone Object(s) to clone the object for safe keeping.
  5. Name the new object End User Anonymous Enrollment Orig.
  6. Click on the tab in the Editor window containing the file End User Anonymous Enrollment work flow.
    This will put the file in focus.
  7. Expand the tree in the Navigator Window to locate the Activity Assimilate User View.
  8. 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.
  9. Save the changes.
  10. Right-click on the file and select IDM > Upload Object(s) to upload the file.

To Use the Identity Manager Debug Pages

  1. Login to the Identity Manager console as administrator.
  2. Go to the debug URL at protocol://IDM-host-machine:port/idm/debug.
  3. Select the object "Task Definition" in the list next to the "List Objects" button.
  4. Click on the "List Objects" button.
  5. Search for the object "End User Anonymous Enrollment" and click on its "edit" hyperlink.
    You might first export the existing definition and save it.
  6. 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.
  7. 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

  1. Go to the OpenSSO login URL at protocol://OSSO-host-machine:port/opensso/UI/Login.
  2. Click the "Register User" button to register a test user.
  3. 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

  1. Login to the Identity Manager console as an administrator.
    The "Create User" pending task is displayed as "Create User ".
  2. Navigate to the "Work Items | Approvals" tab.
  3. Select the provisioning task for the new user-id and click the "Approve" button.
  4. Confirm the approval.
  5. Logout of the Identity Manager console.

C. Verify Provisioning Of New User Account

  1. Login to the OpenSSO console as administrator.
  2. 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

  1. 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.
  2. Logout of OpenSSO.
Now on to another look, Just One Look from Linda Ronstadt.

Posted at 09:06AM Sep 23, 2009 by Michael Teger in Sun  |  Comments[0]

Tuesday Sep 22, 2009

A Good Morning for Single Logout Between Identity Manager and OpenSSO

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.
  1. Log in to the OpenSSO administration console as the administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name and navigate to the agent profile for the policy agent that protects Identity Manager.
  4. Under the agent profile, click the Application tab.
  5. Click Logout Processing.
  6. Add the following map keys and values to the Application Logout URI property:
    • idm=/idm/logout.jsp
    • idm/user=/idm/user/userLogout.jsp
  7. Add the following map and key values to the Logout Entry URI property:
    • idm=/idm
    • idm/user=/idm/user
  8. Click Save.
  9. 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.
  1. Log into Identity Manager.
  2. 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.
  3. 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.

Posted at 09:34AM Sep 22, 2009 by Michael Teger in Sun  |  Comments[4]

Friday Sep 18, 2009

Agents Belong with OpenSSO and Reverse Proxy

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.

Piggybacking on the music videos from Accessing OpenSSO from Outside a Secure Intranet (Put a Lock On It), here's the Taylor Swift video that won the VMA - against Kanye's better wishes.

Posted at 12:00AM Sep 18, 2009 by Michael Teger in Sun  |  Comments[4]

Monday Sep 14, 2009

Accessing OpenSSO from Outside a Secure Intranet (Put a Lock On It)

One of the major decisions in deployment planning is how to set up access to OpenSSO from outside a secure intranet. This information discusses two options: using a reverse proxy or using the Distributed Authentication User Interface (DAUI). Both options allow Authentication Service pages to be served to users over a firewall (for example) thus preventing direct access to OpenSSO by unauthorized users.

Using a Reverse Proxy

As an application proxy does, a reverse proxy acts as a gateway between a protected HTTP server and requests to the HTTP server that originate from outside the secure intranet. A reverse proxy is installed between the outer internet firewall and the inner intranet firewall - in what is referred to as the demilitarized zone (DMZ) - to prevent direct access to the OpenSSO configuration and user data stores by unauthorized users. A reverse proxy can be implemented as Sun Web Proxy Server 4.0.9 or as Sun Web Server 7.0 Update 3 or later with the reverse proxy plugin. It requires an SSL-enabled port for communication between the external client and the back-end OpenSSO server. The following diagram illustrates the deployment.

A reverse proxy is best used when the content to be presented is uniform. This is generally the case when there is only one authentication module or authentication chain configured thus only one user interface page is served and that page is hardly changed. Taking advantage of the caching and compression capabilities of the reverse proxy, the page can be served very quickly. Also using a reverse proxy can be an acceptable and efficient way of distributing the load among web servers. Benefits of reverse proxy servers include:
  • Caching for improved performance When static content is cached, the reverse proxy would not forward a request for the content to OpenSSO; it would respond to the request by serving the content itself. This could lower the request load, thereby improving performance of the server and potentially lower response times to the client.
  • Additional layer of security By introducing an additional layer of security, access to the OpenSSO server is further limited. This additional layer offers the opportunity to monitor traffic, to perform a wider set of checks (for example, malformed URL strings can be stopped at the proxy), and to react to attacks sooner.
  • Persistent load balancing Configure the name of a sticky cookie or sticky URI parameter (in the reverse proxy configuration) to allow subsequent requests to stick to the same OpenSSO server that responded to the first request. Stickiness affects OpenSSO performance positively.
  • Compression for speedy load times Outgoing traffic can be transparently compressed thus lowering total bandwidth requirements. A reverse proxy supports various compression levels and fragment sizes, allowing the administrator to select a level of compromise between speed and compression.
  • Spoon feeding dynamic content Dynamically generated content can be returned from the back end server a little but at a time.
  • Encryption and SSL acceleration.
See the following links for more information.

Using OpenSSO Distributed Authentication User Interface

OpenSSO provides an authentication interface that can be deployed between the outer internet firewall and the inner intranet firewall - in the DMZ - to enable secure authentication communications to the OpenSSO server. Deploying the Distributed Authentication User Interface (DAUI) to one or more web containers within a non-secure layer eliminates the exposure of service URLs to the end user, and prevents direct access to the OpenSSO configuration and user data stores by unauthorized users. The following diagram illustrates the deployment.

The DAUI is best used when various authentication modules/chains are configured and thus customized content needs to be presented to different user clients and/or agents. The DAUI is a flexible option for customizing content in the DMZ. The OpenSSO server is completely hidden from the external clients because all communication is mediated by the OpenSSO Client SDK calls. Benefits of the DAUI include:
  • Eliminate all direct client/server traffic The DAUI receives all client authentication requests and, in turn, sends them to the back-end OpenSSO server, even eliminating encrypted traffic between the external clients and the OpenSSO server.
  • Authentication Service support All authentication modules are supported via the DAUI.
  • Dynamic customization of pages Each incoming request can be routed to different DAUI pages, dependent on the authentication chain or module being used. These DAUI pages are customized in the DMZ so access to the back-end OpenSSO server is not necessary.

See Installing and Configuring the Distributed Authentication User Interface (a portion of the Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0 document) for more information.

Note: The DAUI WAR cannot be used for federation communications between the client SDK in the DMZ and the back-end OpenSSO server. All federation API calls (including SAMLv2, Liberty ID-FF, and Web Services Security) must communicate directly with OpenSSO.

With all the hulabaloo about Kanye West and his interruption of Taylor Swift's acceptance of her MTV video award in Beyonce's name, let's take a look at Single Ladies (Put A Ring On It) (the video Kanye thought should win)...

...and the Bob Fosse choreographed Mexican Breakfast (with Gwen Verdon) that started the whole thing, um, 40 years ago.

Posted at 12:00AM Sep 14, 2009 by Michael Teger in Sun  |  Comments[0]

Friday Sep 04, 2009

OpenSSO Express 8 Shall Be Released

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.

Posted at 08:59AM Sep 04, 2009 by Michael Teger in Sun  |  Comments[0]

Monday Aug 31, 2009

Addicted to Session Attributes in a SAMLv2 Assertion

So you want to copy session attributes and set them to a SAMLv2 assertion? Simply modify the attribute mapping for the identity provider or the remote service provider (you can do it using the OpenSSO console). The default OpenSSO SAMLv2 attribute mapper will find the appropriate attributes in the session and set them in the SAMLv2 assertion.

Now how about Puretone (aka Josh Abrahams featuring Amiel Daemion) and Addicted to Bass?

Posted at 03:06PM Aug 31, 2009 by Michael Teger in Sun  |  Comments[0]

Monday Aug 24, 2009

Breakaway from the Policy Service with OpenSSO Entitlements

Appropos to Dennis's announcement of the Entitlements Service source code being moved into the OpenSSO workspace, here's some information about the developing OpenSSO Entitlements Service.

The Entitlements Service is an authorization and policy component developed for inclusion in the soon-to-be-released OpenSSO Express 8. The user interface provides an easy-to-follow process to define rules for controlling access to applications and web resources. You can create fine-grained policies, and referrals (to assign policy creation based on an OpenSSO realm hierarchy), using these work flows.

The Entitlements Service is being developed in tandem with a new beta OpenSSO administration console. The OpenSSO Enterprise Policy Service, used for more coarse-grained policy implementation, is still available using the standard OpenSSO administration console. See The New OpenSSO Console Rip-Off.

From a high level a service used to create and manage access to web resources consists of the following:
  • A policy administration point (PAP) that comprises the interfaces used to create, read, update and delete the policies.
  • A policy evaluation engine or policy decision point (PDP) that, acting as a policy information point (PIP), is used to query permissions and privileges in order to obtain policy decisions. It gets identity attributes and applicable policies, evaluates the information, and returns the latter with a policy decision to be used for enforcement.
  • A policy enforcement point (PEP) is an agent, installed on the same machine as the resource, that protects it from unauthorized access.
  • A user data store for storing and obtaining identity data.
  • A policy data store for storing policies and the service's configuration attributes, and obtaining said data. (OpenSSO embeds OpenDS for its configuration data store. This configuration data store is used to store Entitlements Service data.)

Different types of resources can be protected by the Entitlements Service. By selecting a general application and adding a more specific resource with applicable subjects and conditions, a policy can be created to define authorization using the new beta console administration interface. An application (term as used in the Entitlements Service) consolidates meta data for generic resource types that share a common set of actions. The format of a resource's definition, supported actions, conditions and subjects, decision combining algorithms (to resolve conflicting policy results) and other data can be defined as a schema for an application. Examples of applications in the Entitlements Service could be calendars, web resources, or user profiles. The following applications are added by default when deploying opensso.war.
  • Web Agent defines actions that can be used to create and manage policies that protect HTTP and HTTPS URLs through the use of a policy agent. This is the most common application use case with the following actions.
    • GET has these operations.
      • Allow: Enables access to the resource defined in the Rule.
      • Deny: Denies access to the resource defined in the Rule.
    • POST has these operations.
      • Allow: Enables access to the resource defined in the Rule.
      • Deny: Denies access to the resource defined in the Rule.
  • Liberty Personal Profile allows administrators to create and manage policies corresponding to actions that can be performed on identity attributes in a personal profile service defined by the Liberty Alliance Project specifications; for example, the OpenSSO implementation of the Liberty Personal Profile Service.
    • MODIFY has these operations.
      • Interact for Value: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol to retrieve a value from a resource in order to modify it.
      • Interact for Consent: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol for consent to modify a value on a resource.
      • Allow: Enables access to the resource defined in the Rule in order to modify an attribute value.
      • Deny: Denies access to the resource defined in the Rule therefore modification is disallowed.
    • QUERY has these operations.
      • Interact for Value: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol to retrieve a value from a resource.
      • Interact for Consent: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol for consent to query a resource.
      • Allow: Enables access to the resource defined in the Rule in order to query the resource.
      • Deny: Denies access to the resource defined in the Rule therefore the query is disallowed.
  • Discovery Service allows administrators to create and manage policies corresponding to actions that can dynamically determine a web services provider (WSP) registered for a particular principal.
    • LOOKUP: Allow or Deny access to search the discovery service.
    • UPDATE: Allow or Deny access to modify data in the discovery service.
A resource is an object on which you can perform an operation or an action. The policy is specifically configured to protect this object. A resource is a string; it could be a URL, a web service, a bank account, or graphical user interface controls (buttons, text fields and the like). Examples could be MyCalendar or other portal type services (located with URLs), a bank account, or a Submit button on a text form.

More information on the Entitlements Service will be forthcoming; these definitions should help you get started, in a small way, by following the inline help developed for the Entitlements Service GUI. But first - enjoy Tracey Ullman singing Breakaway into her hairbrush.

Posted at 09:28AM Aug 24, 2009 by Michael Teger in Sun  |  Comments[0]

Thursday Aug 20, 2009

St. Charles' JSP to Print Session Token Properties

Charles, a Sun QA engineer, recently posted a JSP to the OpenSSO mailing list that allows you to print out the properties (UserID, Principal, Client Address, and the like) populated in an SSOToken. I'm reposting the code here so it doesn't get lost in the maelstrom. 

<%--
   Copyright (c) 2007 Sun Microsystems, Inc. All rights reserved
   Use is subject to license terms.
--%>

<html>
<head>
   
   <title>Show Session Property</title>

   <%@page import="com.iplanet.sso.*" %>

</head>
<body>

<%  
   SSOToken ssoToken = SSOTokenManager.getInstance().createSSOToken(request);
   String value = "";
   String propertyName  = request.getParameter("propertyName");
   if (propertyName != null) {
       value = ssoToken.getProperty(propertyName);
   }
%>

<h1>Session Property</h1>

<form action="show-session-property.jsp" method="POST">
   Property Name <input name="propertyName" value="<%= propertyName %>" size="40"/>
   <p/>
   <input name="submit" type="submit" value="GetValue" />
</form>
<br/>
<%=propertyName%>: <%=value%><br/>
Principal: <%=ssoToken.getProperty("Principal")%><br/>
Principals: <%=ssoToken.getProperty("Principals")%><br/>
UserToken: <%=ssoToken.getProperty("UserToken")%><br/>
UserId: <%=ssoToken.getProperty("UserId")%><br/>
sun.am.UniversalIdentifier: <%=ssoToken.getProperty("sun.am.UniversalIdentifier")%><br/>
Organization :<%=ssoToken.getProperty("Organization")%><br/>
IndexType: <%=ssoToken.getProperty("IndexType")%><br/>
Service: <%=ssoToken.getProperty("Service")%><br/>
AuthType: <%=ssoToken.getProperty("AuthType")%><br/>
AuthLevel: <%=ssoToken.getProperty("AuthLevel")%><br/>
authInstant: <%=ssoToken.getProperty("authInstant")%><br/>
moduleAuthTime: <%=ssoToken.getProperty("moduleAuthTime")%><br/>
amlbcookie: <%=ssoToken.getProperty("amlbcookie")%><br/>
Host: <%=ssoToken.getProperty("Host")%><br/>
CharSet: <%=ssoToken.getProperty("CharSet")%><br/>
Locale: <%=ssoToken.getProperty("Locale")%><br/>
</body>
</html>
In honor of CMW, here's Jefferson Starship and the promotional film (cough, video) for their 1976 single, St. Charles. Although it's a great song, at 6 minutes and 40 seconds, I can see why it peaked at number 64. (Don't ask how I remember these things.)

Posted at 09:23AM Aug 20, 2009 by Michael Teger in Sun  |  Comments[2]

Friday Aug 14, 2009

The New OpenSSO Console Rip-Off

OK, it's not technically a rip-off but that's all I could come up with in the time allotted.

The team of OpenSSO engineers have been working on a new administration console. The plan is to release a beta version of the new console with OpenSSO Express Build 8. Although the trees that contribute to the nightly build and the Express 8 build have not yet been consolidated, portions of the new beta console are available for your perusal in the nightly build. Things will undoubtedly change before the actual release; the following information is so you can take a look at the direction we are going.

This new OpenSSO administration console is in beta and should only be used for test environments. Continue to use the standard OpenSSO administration console for real-time deployments.

After deploying opensso.war to a web container, login to OpenSSO as the administrator and enter protocol://machine.domain:port/deploy-uri/admin in the Location Bar of a browser to display the new console interface.

The Entitlements, Federation and Web Service Security tabs comprise the bulk of features currently in this new console. Accommodations have been made for these features by providing inline help displayed on the console screen. Additional documentation will be available after the beta release. Working With the Entitlements Service The Entitlements tab contains the new work flows for ease-of-use when creating new, and managing existing, policies for the new Entitlements Service. These features are only available in the beta administration console. You must choose the framework with which you will be creating policies for your resources. The options are the Policy Service using the standard administration console and the Entitlements Service using the beta administration console. Once the choice is made (by creating and saving a policy using one or the other), only that service (Entitlements or Policy) will be enabled. Migration of policies from previous versions of OpenSSO is not supported.

Using the Federation Work Flows The Federation tab contains the new work flows for ease-of-use when creating and registering entity providers for the Federation Service using the SAMLv2 protocol. These work flows are available in either the standard or beta administration console. If you create SAMLv2 entity providers using the work flows in the beta administration console, you manage the configurations using the standard administration console.

Using the Web Services Security Work Flows The Web Service Security tab contains the new work flows for ease-of-use in creating profiles to work with the Web Service Security framework. These work flows are available only in the beta administration console although profiles can also be created by manually configuring attributes using the standard administration console. You can create profiles in the beta console and manage them in the standard console.

Displaying Realms The intent with the beta administration console is to hide realms. If no realms are configured using the standard console, the applicable interface to switch realms will not be visible in the beta console, nor anything about referrals. If you create a realm using the standard console, realm and referral menu items are visible.

Now enjoy the greatly, soulful Laura Lee and her 1972 hit, Rip-Off.

Posted at 10:22AM Aug 14, 2009 by Michael Teger in Sun  |  Comments[0]

Monday Aug 10, 2009

Store & Retrieve Authentication Info with OpenSSO, She & Him

Here are some words on storing authentication information in an OpenSSO session and retrieving it. It assumes that the authentication module extends AMLoginModule and the information is to be shared with a post authentication plug-in.

If the size of the information is small, you can store it in the SSOToken. If the information is security sensitive and not to be readable by the Client SDK, you could encrypt it before setting it in the SSOToken. (Prefixing the property name with am.protected. defines it as NOT readable by the Client SDK.)

After you put the required information from the authentication module into the module principal class, implement the com.sun.identity.authentication.service.AuthenticationPrincipalDataRetriever interface. It has the following method to get the module principal from authSubject, retrieve the required data, and return that data as a Map (key/value pairs). 
    /**
     * Returns the attribute map from the required Authentication module
     * Principal, to be set in the SSOToken.    
     *
     * @param authSubject Authenticated user Subject.
     * @return the Attribute Map.
     */
    Map getAttrMapForAuthenticationModule(Subject authSubject);
The Authentication Service will store this Map in the authenticated SSOToken. A post authentication plug-in can retrieve this data from the SSOToken later. You will need to set your implementation class as a value of the com.sun.identity.authentication.principalDataRetriever property in the OpenSSO configuration data store.

Now here is Zooey Deschanel and M. Ward, plugged in as She & Him. Why Do You Let Me Stay Here? is from their album, Volume 1. I love M (especially his album Transistor Radio), love Zooey (especially as an actress in the ScyFy take on Oz called Tin Man) and also Zooey's sis, Emily (especially as the femme lead on Bones). The video is quirky and endearing and bloody.

Posted at 09:13AM Aug 10, 2009 by Michael Teger in Sun  |  Comments[0]

Monday Aug 03, 2009

Don't Stop Believin' in the OpenSSO Public Javadoc

I was contacted by an OpenSSO engineer last week who wanted to know where she could get the latest Java API Reference documentation - that's the real name for the untrademarked Javadoc. I was surprised at the request because I thought anyone who was anyone in the community knows that the Java API Reference is available in the nightly build (and has been for a while). So, for others who might not know, here is how to open and display the public Java API Reference from opensso.zip.

  1. Download opensso.zip.
  2. Decompress opensso.zip.
    The files are unzipped into the opensso directory.
  3. Change into the /opensso/docs directory.
  4. Decompress opensso-public-javadocs.jar.
    jar xvf opensso-public-javadocs.jar
  5. From a local browser, choose File -> Open File.
  6. Navigate to the docs folder from within the Open File window.
  7. Select index.html to open in the browser window.
    index.html is the public home page for the Java API Reference.
Because of the ease with which you can now access them, the Java API Reference will no longer be published as part of the documentation set for releases of OpenSSO. So remember this procedure!

How many thought I might be linking to Journey's Don't Stop Believing? I could've even used the version from Glee. Well, I'm not that predictable. (Note the spelling of believin'.) Here is Olivia Newton-John singing the tune that kept my spirits up as I failed two tests for my driver's license in 1975 and waited to take the third. I listened to this for days before that final test. I didn't stop believin', passed the third test and having been driving offensively ever since.

Posted at 01:56PM Aug 03, 2009 by Michael Teger in Sun  |  Comments[0]

Thursday Jul 30, 2009

OpenSSO's Secret Place

Look in the OpenSSO-Deploy-Base*/opensso directory and you'll find ssoadm.jsp. This best kept secret is the web version of the ssoadm command line interface and can be used as such - although it's technically a secret. So check it out but don't tell them I sent you.

And now listen to Joni Mitchell and Peter Gabriel singing My Secret Place.

* OpenSSO-Deploy-Base represents the directory in which your particular web container deploys the opensso.war.

Posted at 02:44AM Jul 30, 2009 by Michael Teger in Sun  |  Comments[0]

Wednesday Jul 29, 2009

OpenSSO ASP.NET Fedlet, Multiple Identity Providers and An Angel's Kiss in Spring

I was reading the latest scoop on The Whalpin Chronicles when I found a comment from someone requesting information on how to configure the ASP.NET Fedlet with multiple identity providers. Sure there's a README now but in a week or so this will be official. As Whalpin said, check out the nightly.

This procedure can be followed to enable the ASP.NET Fedlet to communicate with multiple identity providers. It assumes that you have already followed the instructions in Using the ASP.NET Fedlet with OpenSSO Enterprise 8.0 Update 1 to configure and test the ASP.NET Fedlet with an initial identity provider.
  1. Get the standard metadata file for the new identity provider and name it idp2.xml.
    If using OpenSSO, create the identity provider using the Common Tasks work flow and export the identity provider's standard metadata by accessing the export metadata page at http://idp-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp.
  2. Copy idp2.xml to the directory created during initial configuration of the ASP.NET Fedlet.
    During initial configuration, move the /SampleApp directory from the Fedlet-unconfigured.zip file to a directory outside of the decompressed archive. For this article, we will use /tmp/asp.net/SampleApp/App_Data/. See Using the ASP.NET Fedlet with OpenSSO Enterprise 8.0 Update 1 for more information.
  3. Add the identity provider to the appropriate circle of trust by modifying the Fedlet's .COT file.
    1. To add to an existing circle of trust, append the entity ID of the new identity provider (specified by the entityID attribute in the idp2.xml metadata) to the value of the sun-fm-trusted-providers attribute in the appropriate .COT file (for example, fedlet.cot) within the /tmp/asp.net/SampleApp/App_Data/ directory.
      Use a comma (,) as the separator.
    2. To add to a new circle of trust follow this procedure.
      1. Create a new .COT file named (for example, fedlet2.cot) using the existing fedlet.cot as a template.
      2. Change the value of the cot-name attribute in the new .COT file to the name of the new circle of trust.
      3. Add both the new identity provider entity ID and the Fedlet entity ID as the value for the sun-fm-trusted-providers attribute in the new .COT file.
        Use a comma (,) as the separator.
      4. Put fedlet2.cot in the /tmp/asp.net/SampleApp/App_Data/ directory.
      5. Add the new circle of trust name to the value of the cotlist attribute in the ASP.NET Fedlet/service provider extended metadata file, sp-extended.xml.
        For example:
        <Attribute name="cotlist">
        <Value>saml2cot</Value>
        <Value>cot2</Value>
        </Attribute>
         sp-extended.xml is in the /tmp/asp.net/SampleApp/App_Data/ directory.
  4. Create a new file named (for example, idp2-extended.xml) to define the extended metadata for the new identity provider using the existing idp-extended.xml as a template.
    1. Change the value of the entityID attribute to the entityID of the new identity provider.
    2. IF APPLICABLE, change the value of the cotlist attribute to the name of the new circle of trust.
    3. IF APPLICABLE, change the setting of the hosted attribute in the EntityConfig element to false to define it as a remote identity provider.
  5. Send the ASP.NET Fedlet/service provider standard metadata (for example, sp.xml) found in the /tmp/asp.net/SampleApp/App_Data/ folder to the second identity provider.
  6. Import the ASP.NET Fedlet/service provider standard metadata to the appropriate circle of trust on the identity provider side.
    If using OpenSSO, use Register Remote Service Provider under the Common Tasks tab.
  7. Repeat these steps for any number of identity providers using the circle of trust and file-naming formats as discussed.
  8. Using the Internet Information Services (IIS) Manager, restart the Application Pool associated with the ASP.NET application.
    Each ASP.NET web application hosted on IIS is associated with an Application Pool that controls the application's runtime behavior (for example, session properties, memory allocation and garbage collection).
If you use the Sample Application return to the default page for a list of identity providers from which to choose. See To Configure the Sample Application and Test the ASP.NET Fedlet.

Now relax with a glass of Summer Wine as made by Nancy Sinatra and Lee Hazlewood. Strawberries, cherries, and an...oh, you know the rest.

Posted at 09:25AM Jul 29, 2009 by Michael Teger in Sun  |  Comments[0]

Thursday Jul 16, 2009

I Want Web Services Security To Work With One Instance of OpenSSO

Securing web services communications using OpenSSO entails embedding security information within the SOAP request sent to the web service provider (WSP), and within the response returned to the web service consumer (WSC). The communications may then securely pass through multiple intermediaries (firewalls and load balancers, for example) before reaching its intended receiver. The following sections illustrate how to configure and test secure web services communications using OpenSSO and included samples.

In this simple scenario, the message security is achieved using an instance of OpenSSO that communicates with a security agent deployed on both the WSC and WSP sides. The agent profiles for the deployment are configured using OpenSSO. The following procedures illustrate how to configure for web services security and test the configurations using the OpenSSO Stock Quote Service sample.

The first steps are to install three instances of Glassfish Application Server to host the WSC, the WSP and OpenSSO respectively. (Alternately, you can install one Glassfish instance and configure three different domains to host the WSC, the WSP and OpenSSO.) When finished with Glassfish, install OpenSSO. Instructions to install Glassfish and OpenSSO can be found in this (admittedly old but still valid with more recent downloads) blog entry or in the official documentation for Glassfish and OpenSSO. After completing these installations, proceed down the following list of procedures.

Installing a Web Services Security Agent

Follow this procedure to install each security agent with the Express Build 8 installer (not yet released). Before Express Build 8, use the old installer.
  1. Create a text file that contains the agentAuth password in clear text and save it.
    Configured out of the box, agentAuth is an agent profile with permission to read other configured agent profiles including the default wsc, wsp and SecurityTokenService. The agentAuth password is changeit.
  2. Download openssowssproviders.zip.
  3. Create a directory to which you will inflate the ZIP.
    % mkdir /tmp/wssunzip (or \wssunzip on Windows)
  4. Unzip openssowssproviders.zip to the directory.
  5. Stop the Glassfish instance on which the agent is to be installed.
  6. Begin the installation with one of the following steps.
    • On UNIX and Linux, change to the /tmp/wssunzip/bin directory and run chmod 755 wssagentadmin. Following that, run ./wssagentadmin --install or ./wssagentadmin --custom-install.
    • On Windows, change to the \wssunzip\bin directory and run wssagentadmin.bat --install or wssagentadmin.bat --custom-install.
    Both options install the agent but --custom-install allows you to specify the application server instance name whereas the --install assumes the instance name to be server.
  7. Review the license information, if applicable.
  8. Enter the absolute path of the application server domain configuration directory.
  9. Enter the application server instance name if you ran the installer with the --custom-install option.
    In the case of Sun Application Server Enterprise Edition, a domain can have more than one application server instance so enter the name of the application server instance in which you are installing the agent.
  10. Enter the OpenSSO deployment URL using the format protocol://host:port/deployURI.
    protocol is either http or https; host is the fully qualified domain name of the machine on which OpenSSO is running and deployURI is the OpenSSO deployment URI; by default, opensso.
  11. Enter agentAuth, the user with permission to read the agent profiles.
  12. Enter the path to the agentAuth password file created at the beginning of this procedure.
  13. Review the summary and choose Continue with Installation to begin the process.
  14. Restart the Application Server instance or domain after installation is complete.

Adding Java Security Permissions

If the Glassfish Security Manager is enabled, you must add Java security permissions to all domains used in this deployment. If, for example, the WSC and WSP are deployed in one domain, edit only one server.policy file for the both.
  1. Append the Java security permissions defined in /tmp/wssunzip/config/OpenSSOJavaPermissions.txt to the server.policy file of the specific Application Server domain.
    Each Application Server domain has its own standard J2SE policy file named server.policy located in the /ApplicationServer-install/domains/domain-name/config directory.
  2. Restart the Application Server instance.

Deploying the Web Service Client and Web Service Provider Application Sample

The web services security sample contains the /tmp/wssunzip/samples/glassfish/StockQuoteClient and /tmp/wssunzip/samples/glassfish/StockService directories for the client and provider respectively. A /tmp/wssunzip/samples/glassfish/glassfish.properties file contains the configuration properties for Glassfish.
Deploying the Web Service Client Sample
  1. Create a password file for the Glassfish administrator.
    The password file should have read permissions and the line AS_ADMIN_password=password
  2. Edit glassfish.properties as follows: glassfish.home = WSC Glassfish installation directory (for example, /export/glassfishv2ur2/glassfish) glassfish.host = WSC Host where glassfish is installed (for example, opensso.sun.com) glassfish.passwordfile = path to Glassfish administrator password file (for example, /tmp/GFadmin_passwd)
  3. Set JAVA_HOME to JDK1.5 or 1.6 and ensure java and javac are in the PATH.
  4. Replace localhost and 8080 in the StockQuoteClient/src/java/com/samples/GetQuote.java and StockQuoteClient/src/java/com/samples/SOAPMessage.java files with the fully qualified domain name and port to which the web service provider was deployed.
    localhost and 8080 are the default OpenSSO values. These files would need modification if you changed the values for the web service provider during installation.
  5. Change to the StockQuoteClient directory and run WSC-ApplicationServer-install/lib/ant/bin/ant all.
    This will build and deploy the Stock Quote Sample Client to the WSC Glassfish container.
Deploying the Web Service Provider Sample
  1. Create a password file for the Glassfish administrator.
    The password file should have read permissions and the line AS_ADMIN_password=password
  2. Edit glassfish.properties as follows: glassfish.home = WSP Glassfish installation directory (for example, /export/glassfishv2ur2/glassfish) glassfish.host = WSP Host where glassfish is installed (for example, opensso.sun.com) glassfish.passwordfile = path to Glassfish administrator password file (for example, /tmp/GFadmin_passwd)
  3. Set JAVA_HOME to JDK1.5 or 1.6 and ensure java and javac are in the PATH.
  4. Change to the StockService directory and run WSP-ApplicationServer-install/lib/ant/bin/ant all.
    This will build and deploy the Stock Quote Sample Service to the WSP Glassfish container.

Creating the WSC, WSP and STS Agent Profiles Using OpenSSO

The agent profiles for a WSC (wsc), a WSP (wsp), and a Security Token Service (SecurityTokenService) are created when OpenSSO is installed. These can be used with the sample.
Configure the WSC Agent Profile
  1. Login to the OpenSSO console as the administrator; by default, amadmin.
  2. Click the Access Control tab.
  3. Click the top level realm.
  4. Under the Agents tab, click Web Service Client.
  5. OPTIONAL: Click New to create the WSC agent profile if you do not see the default wsc in the table.
    1. Enter wsc as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  6. Click wsc from the table to access the profile.
  7. Select the appropriate Security Mechanism.
    If you select STSSecurity as Security Mechanism, the WSC is requesting that the OpenSSO Security Token Service (STS) generate a token to secure the request to the WSP. See To Configure the STS Agent Profile to create a profile for the Security Token Service.
  8. Check Is Request Signed.
  9. Check Preserve Security Headers in Message.
  10. Specify http://wsp-host-name:portnumber/StockService/StockService as the Web Service End Point.
  11. Save the changes.
  12. Click Back to Main Page.
Configure the Security Token Service Agent Profile
If you did not select STSSecurity as the Security Mechanism in To Configure the WSC Agent Profile, skip this procedure.
  1. Under the Agents tab, click STS Client.
  2. OPTIONAL: Click New to create the Security Token Service agent profile if you do not see the default SecurityTokenService in the table.
    1. Enter SecurityTokenService as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  3. ClickSecurityTokenService from the table to access the profile.
  4. Select the appropriate Security Mechanism.
  5. Enter openssoserver_protocol://openssoserver_host:port/openssoserver_deploy_uri/sts as the Security Token Service End Point.
  6. Enter openssoserver_protocol://openssoserver_host:port/openssoserver_deploy_uri/sts/mex as Security Token Service MEX End Point.
  7. Save the changes.
  8. Click Back to Main Page.
Configure the WSP Agent Profile
  1. Under the Agents tab, click Web Service Provider.
  2. OPTIONAL: Click New to create the WSP agent profile if you do not see the default wsp in the table.
    1. Enter wsp as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  3. Click wsp from the table to access the profile.
  4. Select all Security Mechanism choices.
  5. Check Is Request Signature Verified.
  6. Check Preserve Security Headers in Message.
  7. Specify http://wsp-host-name:portnumber/StockService/StockService as the Web Service End Point.
  8. Save the changes.
  9. Click Back to Main Page.
Review the Agent Authenticator Profile
  1. Under the Agents tab, click Agent Authenticator.
  2. Click agentAuth.
  3. Confirm that wsp, wsc, and SecurityTokenService have been added to the Selected list under the Agent Profiles allowed to Read attribute.
    If not, add them into the list and save the changes.
  4. Log out of the OpenSSO console.

Testing the Sample

  1. Access the stock quote client page at http://wsc-host-name:portnumber/StockQuoteClient/index.jsp.
    The browser will be redirected to the OpenSSO Authentication Service.
  2. Enter the user name and password of an existing OpenSSO user.
    Upon successful authentication, the browser is redirected back to the Stock Quote Service.
  3. Enter "JAVA" (or any other stock symbol) and click Get Quote.
    Stock quote information for the entered symbol is displayed.

And now that you've tested your web services security, check out Bow Wow Wow's video for I Want Candy.

Posted at 10:57AM Jul 16, 2009 by Michael Teger in Sun  |  Comments[2]

Wednesday Jul 08, 2009

OpenSSO Under Replay Attacks

A replay attack occurs when a valid data transmission is maliciously intercepted and retransmitted. Digital signatures alone do not provide protection against replay attacks in web services communications as a signed message can still be recorded and resent. The WS-Security specification recommends a number of options to protect against replay attacks; from those options, the OpenSSO web services framework has implemented the use of the time stamp. That said, here is some preliminary information about preventing replay attacks using OpenSSO.

More to come. Below is subject to tweak. But you got it first.
The OpenSSO web services security framework is driven primarily by security agents that install on deployed web containers remote to OpenSSO. The security agent accesses the web services security framework using the SOAPRequestHandler interface in the Client SDK to validate SOAP messages and authenticate against OpenSSO. As part of the process, digital signatures and encryptions are validated and, following that, the message's time stamp is processed to check for replay attacks. The time stamp can be processed using either of the following options.
  • MessageID
    The WS-Addressing MessageID header can be optionally included in a SOAP message. The value of the MessageID from a first request is cached. The messageIDMap cache uses the MessageID value to index the local time stamp (stamped when the message is received). Any message requests that use the same MessageID and are found to be within a configured time interval will be treated as a duplicate and will be rejected. (If a MessageID is not found in the incoming SOAP request, the authenticated subject identifier is used to index the time stamp.)

  • nonce
    If implementing the Username Token profile for web services security, you can cache the cryptographically random value of the nonce element from each initial request. The messageIDMap cache uses the nonce value to index the creation time stamp (time at which the token was generated). Any message requests that use the same nonce and are found to be within a configured time interval will be treated as a duplicate and will be rejected.

The Client SDK can not use the high availability and failover features of OpenSSO. Thus, the solution is to provide an interface to use for persistent storage of the state of the cache on the web services provider side. The com.sun.identity.wss.security.handler.WSSCacheRepository interface assumes a repository has already been configured and the cache can be persistently stored in it. There is no out of the box implementation for this interface but the name of the implementation class, if developed, needs to be entered as the value of the com.sun.identity.wss.security.cacherepository.plugin attribute in the AMClient.properties file. To enable the replay attack prevention feature, you create a web services provider agent profile under the appropriate realm. Once the profile has been created, follow this procedure.
  1. Click the name of the realm in which the agent profile was created.
  2. Click the Agents tab.
  3. Click the Web Service Provider tab.
  4. Click the name of the appropriate web service provider profile.
  5. Enable Detect Message Replay if applicable.
    This enables the MessageID option.
  6. Enable Detect User Token Replay if applicable.
    This enables the nonce option.
  7. Save the configuration.
You also need to add the web service client instance of OpenSSO and the Security Token Service instance of OpenSSO as a value in the Trusted Server listing. The cache is cleaned up using a periodic cleanup thread with a configurable time interval.

And now ABBA, a group that knows something about being Under Attack.

Posted at 12:00AM Jul 08, 2009 by Michael Teger in Sun  |  Comments[0]