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

NOTE: If the value of the parameters (value1, value2, ..., valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

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.

Sunday Oct 04, 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.

Thursday Oct 01, 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.

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?

Sunday Sep 27, 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).

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.

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.

Thursday Sep 17, 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.

Sunday Sep 13, 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.

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.

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?

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.

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


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.


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.

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.

Wednesday Jul 29, 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.

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.

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.


Tuesday Jul 07, 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.

Wednesday Jul 01, 2009

Synchronizing OpenSSO SAMLv2 Sessions Doesn't Make Me Anxious Anymore

After a successful SAMLv2 single sign-on, sessions are created on both the identity provider side and the service provider side. The sessions are independent from each other with their own maximum session time out and idle time out values so if one session times out or is destroyed locally, the other will not be notified. This results in an inconsistent session state between the two providers. For the upcoming Express Build 8 release, OpenSSO has added a new configuration property to support session synchronization between the two providers. The service provider will notify the identity provider when a session is refreshed (by access) or at a fixed interval.

The Session Synchronization attribute (available only in builds later than OpenSSO Enterprise 8.0) is displayed only after creating a SAMLv2 hosted identity or service provider configuration first. See Part II Federation, Web Services, and SAML Administration in the OpenSSO Enterprise 8.0 Administration Guide. Following that, under the Federation tab, click the name of the appropriate provider to display its attributes. Under the Advanced tab is the Session Synchronization attribute which can be enabled for a hosted SAMLv2 provider. If session synchronization is enabled for the hosted identity provider and a session times out (due to hitting a maximum idle time out value or maximum session time value), the identity provider will send a SOAP logout request to all affected service providers. If session synchronization is enabled for the hosted service provider, it will send a SOAP logout request to all affected identity providers.

A few weeks back, I posted an article on one time password authentication with a musical clip of The Beautiful South. The Beautiful South was one fork that grew after the breakup of The Housemartins. (The other was Fatboy Slim.) In that vein, here is an excellent live clip of The Housemartins performing Anxious from their debut LP.

I miss The Housemartins.

Tuesday Jun 30, 2009

OpenSSO Resource Authentication Is Not The Gateway Servlet

In previous versions of OpenSSO, the Gateway Servlet was used to authenticate against an authentication module configured to protect a specific resource. This resource authentication type though was developed using the Policy Service framework and contains limitations. With the iminent release of OpenSSO Express Build 8, resource authentication becomes available as part of the Authentication Service framework - without calling the Gateway Servlet (which will be deprecated in a future release).

Resource authentication is based on the client environment parameters defined in the HTTP header of the request. After receiving a request for access, the Authentication Service passes the resource name and appropriate environment parameters to the Policy Service to determine the authentication type to be used. (Resource authentication is parallel to the other authentication types but, because the authentication process is based on environment variables, resource authentication will ultimately run one of the other configured authentication types rather than having a fixed authentication process itself.) The Policy Service returns an advice message to indicate the appropriate authentication type to call. The user is then prompted for the appropriate credentials for the authentication type and, if successful, continues the process with session validation as documented in the Sun OpenSSO Enterprise 8.0 Technical Overview. The process flow diagram illustrates this.

To use resource authentication, you need to create a policy with a condition that defines the authentication process for the protected resource, and to define a login URL to call the authentication process based on the resource. If there is no policy defined for the protected resource, the user will be prompted from the default authentication process defined for the realm.

In the following formats for the IF/THEN condition, Environment_Name is a URL query parameter or an HTTP header attribute, Authentication_Type is one of the OpenSSO authentication types (module, user, role, service or authlevel), and Authentication_Process is a configured authentication process (either an instantiated authentication module or authentication chain).

  • IF Environment_Name=value THEN Authentication_Type=[realm:]Authentication_Process
    This means if the IF condition is satisfied, the user will attempt authentication using the authentication process defined by THEN.
  • IF Environment_Name=value THEN realm=realm_name
    This means if the IF condition is satisfied, the user will attempt authentication using the authentication process defined for the specified realm.
  • IF Environment_Name=value THEN redirectURL=redirect_URL
    This means if the IF condition is satisfied, the user will be redirected to the URL specified as a value for redirectURL parameter.

More information will be forthcomingwhen Express Build 8 is released. Check the OpenSSO Resource Center for any new documentation.

And in tribute to the musical genius that was Michael Jackson, here is his masterful performance of Billie Jean on Motown 25 when a little moonwalk blasted him into the stratosphere.

Thursday Jun 18, 2009

Moving OpenSSO Session Cookie Hijacking Information

In reorganizing and rewriting the OpenSSO Enterprise 8.0 Administration Guide, I thought the chapter on session cookie hijacking was in the wrong place. The Administration Guide is a guide for administering and configuring OpenSSO Enterprise using the console and the command line. The information in the session cookie hijacking chapter, with its emphasis on a technical overview, security issues and configuration seemed more inline with a task that would be done post OpenSSO installation and deployment. Thus the chapter was moved, intact, to the OpenSSO Enterprise 8.0 Installation and Configuration Guide.

So, if looking for information on session cookie hijacking, check out Chapter 19, Taking Precautions Against Session-Cookie Hijacking in an OpenSSO Enterprise Deployment in the aforementioned ICG.

And speaking of moving, here's Kate Bush, live at the Hammersmith Odeon, with the first cut from The Kick Inside, Moving.

Move over, Madonna. THIS was the first time I had seen anyone use the telephone operator microphone in a live performance.

Monday Jun 15, 2009

OpenSSO One Time Password Authentication is the One That I Want

OpenSSO now contains a one time password authentication module. The one time password implementation can be configured as a two-factor authentication where the authentication process comprises something the user has as well as something the user knows. In other words, when the HMAC-based One Time Password (HOTP) authentication module is configured as part of an authentication chain with, for example, the LDAP authentication module, the user must authenticate using the configured LDAP directory as well as a one time password.

The HOTP authentication module works in tandem with one or more other authentication modules. Authentication to at least one of the other modules must be successful before attempting HOTP authentication as it requires the user identifier identified by a first authentication module. When the user attempts to log in to the OpenSSO console using an authentication chain configured with, for example, LDAP and HOTP, the LDAP authentication module login page is displayed. The user submits a valid LDAP user name and password - something the user knows. After successful authentication to the LDAP module, the HOTP authentication module login page is displayed.

The user clicks the Request OTP Code button to request that a one time password be sent to something the user has: a cell phone or an email account. The one time password will then be sent to the phone number or email address configured in the user's profile, retrieved by the user, entered in the OTP Code field on the login page, and submitted to OpenSSO. Assuming successful authentication, access to the protected resource is allowed.
NOTE: In order to communicate the one time password securely between parties, a hashed message authentication code (HMAC) is used to encode the data. When a one time password is requested, the HOTP authentication module stores the OTP in memory, appends an authentication tag to it that is computed as a function of the one-time password and the HMAC, and sends it to the user. When the user returns the one time password, the HOTP authentication module will compare the one received with the one it stores in memory and authentication succeeds only if the values match. The use of the HMAC algorithm is standardized in HOTP: An HMAC-Based One-Time Password Algorithm.
You can configure the user profile to receive the one time password via email or text message.

  • To receive a one time password via email, the Email Address attribute in the user's profile must be populated with a valid email address.
  • To receive the one time password via text message, the Telephone Number attribute in the user's profile must be populated with a ten digit mobile phone number. The phone number must be compatible with the Short Message Service (SMS), a standardized communication protocol that allows for the interchange of short text messages to mobile telephone devices. Additionally, the phone number must be appended with the provider's domain; for example, 14085551212@txt.att.net or 14085551212@messaging.sprintpcs.com. If the phone number is provided without a provider domain, the default domain txt.att.net will be appended to the phone number.

The OpenSSO administrator configures values for the following HOTP authentication module properties.

  • Authentication Level defines a value (set in reference to other enabled authentication modules) to indicate how much to trust HOTP authentications. For example, a human resources application might require level 5 authentication for access while the company directory only level 1. These values are used when defining policies for these resources to ensure the right level of authentication for higher trust resources. For more information on how the authentication level value works, see Authentication Level-based Authentication.
  • SMS Gateway Implementation Class defines a custom implementation of the public service provider interface (SPI) SMSGateway.java. The default implementation is com.sun.identity.authentication.modules.hotp.DefaultSMSGatewayImpl. This class sends the one time password to an email address or to a mobile device, depending on the configuration.
  • SMTP Host Name defines the machine and domain name of the outgoing mail server used to send the one time password to an email address. (SMTP is an acronym for Simple Mail Transfer Protocol, a standard used for email transmission.) There can only be one SMTP server per realm. OpenSSO supports mail servers that require user authentication in order to send email.
  • SMTP Host Port defines the port number of the outgoing mail server.
  • SMTP User Name defines the administrative user that will authenticate to the outgoing mail server for email transmission.
  • SMTP User password defines the password for the SMTP administrative user.
  • SMTP User password (confirm) confirms the password for the SMTP administrative user.
  • SMTP Connection defines whether the SMTP server uses the Secure Sockets Layer (SSL).
  • One Time Password Validity Length (in minutes) defines the amount of time for which the one time password will be valid. When the one time password code is generated, a creation time for it is recorded by the module. When the module receives the code back from the user, it checks the current time against the creation time to see if it has exceeded the maximum validity time.
  • One Time Password Length (in digits) defines whether the one time password is six or eight digits.
  • One Time Password Delivery defines whether the one time password is delivered via email or SMS text message to a cell phone. If email is selected, the user will receive an email with the one time password code if the user profile contains a valid email address. If SMS is selected, the user will receive the one time password code on a cell phone if the user profile contains a phone number. If both options are selected (the default value), the user will receive the one time password code through email and text. If the user profile does not contain the required email address or phone number, the HOTP authentication module will time out and user authentication will fail.

After configuration, the administrator creates an authentication chain using the HOTP authentication module with at least one other authentication module. (HOTP authentication can not be the first module in the authentication chain as it uses the user identifier garnered by the first module in the chain.) Following creation of the authentication chain, the administrator creates a policy for the appropriate resource using the authentication chain as the policy condition.

Test HOTP authentication using the following procedure.

  1. Create an authentication chain that contains the two authentication modules; for example, Data Store and HOTP.
  2. Add an email address or telephone number to the Demo user profile.
  3. Access the chain for authentication with the following URL: http://server:port/opensso/UI/Login?service=configured-auth-chain
    The Data Store authentication module page is displayed.
  4. Enter a user name and password.
    Use the default user demo and corresponding password changeit. Authentication is successful to the Data Store authentication module and the HOTP authentication module page is displayed.
  5. Click Request HOTP Code on the HOTP login page.
    The one time password will be sent to one or both: the email address and phone number.
  6. Enter the received HOTP code in the HOTP Code field and click Submit HOTP Code.
    Authentication is successful to the HOTP authentication module.

You can also:

  • Change the value of One Time Password Length and repeat the authentication steps to see the alternate code length.
  • Change the value of One Time Password Validity Length and repeat the authentication steps. For example, change the value to 1 (minute) and wait longer than one minute before submitting the code. HOTP authentication will fail.
  • Test authentication using the HOTP authentication module with a policy agent by defining a policy that uses the authentication chain to protect the resource.

The forceAuth=true parameter can be used to force user authentication for purposes of session upgrades. When this parameter is appended to the end of the authentication URL, the existing session token will be updated on successful authentication.

And now to the music: in 2004 the Beautiful South released Golddiggas, Headnodders and Pholk Songs, an album of covers. The first cut was the Olivia Newton-John/John Travolta hit from Grease, You're The One That I want. Here's a live version from the Jools Holland TV show. You've never heard it like this.

I miss the Beautiful South!

Friday May 08, 2009

An ASP.NET OpenSSO Fedlet? Sign of the Times

In light of the OpenSSO Fedlet's recent award for innovation, here are instructions to configure and test the new ASP.NET Fedlet.

The Fedlet is a small archive that can be embedded into a service provider's web application to allow for SAMLv2 single sign-on between an identity provider instance of OpenSSO and the service provider application - WITHOUT installing OpenSSO on the service provider side. With the upcoming release of OpenSSO Enterprise 8.0 Update 1, the Fedlet technology has been extended to the ASP.NET platform. The code is currently available in the nightly builds.

OpenSSO Enterprise 8.0 Update 1 includes the Fedlet.dll, template metadata files, and a sample ASP.NET application for testing the communications. The Fedlet.dll initiates single sign-on with an identity provider and enables the receipt of an authentication response by the service provider using an HTTP-POST binding.

To configure the Sample Application for communications with the ASP.NET Fedlet, follow these first three procedures. The final procedure has the ASP.NET code to use in an existing application.

To Configure the Identity Provider

  1. Create the hosted identity provider using the Common Tasks work flow in the OpenSSO Enterprise console.

    You will need the name of the circle of trust in To Configure the Service Provider and the ASP.NET Fedlet.
  2. Export the identity provider's standard metadata file.

    idp.xml can be exported by accessing the export metadata page at http://idp-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp
  3. Register the remote service provider using the modified standard metadata file sp.xml and the Register Remote Service Provider work flow in the OpenSSO Enterprise console.

    This standard metadata is modified in To Configure the Service Provider and the ASP.NET Fedlet thus, registering the service provider on the identity provider machine is the last step of that procedure.

To Configure the Service Provider and the ASP.NET Fedlet

  1. Download the OpenSSO Enterprise ZIP archive to the service provider machine and unzip it.
  2. Unzip the Fedlet-unconfigured.zip in the /opensso/fedlet/ folder.
  3. Move the /opensso/fedlet/asp.net/ folder to a temporary directory.
  4. Change to the /tmp/asp.net/conf directory.
  5. Make copies of the template files.
    • Copy sp.xml-template to sp.xml.
    • Copy sp-extended.xml-template to sp-extended.xml.
    • Copy idp-extended.xml-template to idp-extended.xml.
    • Copy fedlet.cot-template to fedlet.cot.

  6. Swap out the following tags in the copied metadata files.

    • Replace FEDLET_COT with the name of the circle of trust of which the remote identity provider and the local service provider are members.
    • Replace FEDLET_ENTITY_ID with a unique identifier used to locate the Fedlet. This value is analogous to the service provider EntityID. The EntityID attribute is under the EntityDescriptor element that is passed to the service provider as part of the XML exchange. The Name attribute of a configured entity provider when looking in the OpenSSO console is the value of the EntityID.
    • Replace FEDLET_URL with the URL of the Fedlet; for example, http://sp-machine.domain/SampleApp/fedletapplication.aspx.
    • Replace IDP_ENTITY_ID with the entity ID of the remote identity provider. The EntityID attribute is under the EntityDescriptor element that is passed to the service provider as part of the XML exchange. The Name attribute of a configured entity provider in the OpenSSO console is the value of the EntityID.
  7. Return to the identity provider machine to register the service provider using the modified sp.xml file and making sure to associate the service provider and the identity provider with the same circle of trust.

To Configure the Sample Application and Test the ASP.NET Fedlet

The Sample Application should be deployed using ASP.NET version 3.5 and Microsoft Internet Information Server versions 6 or 7.

  1. Navigate to the /tmp/asp.net/conf folder on the service provider machine.
  2. Copy the modified metadata files idp-extended.xml, sp.xml, sp-extended.xml, and fedlet.cot) to /tmp/asp.net/SampleApp/App_Data/.
  3. Copy the remote identity provider's standard metadata file to the service provider machine.

    Be sure the file is named idp.xml.
  4. Place idp.xml in /tmp/asp.net/SampleApp/App_Data/.
  5. Confirm that the Fedlet.dll is in the Sample Application's /tmp/asp.net/SampleApp/bin/ folder.
  6. Within Internet Information Server (IIS), create a virtual directory using the /tmp/asp.net/SampleApp/ directory.

    • IIS 6 (Windows 2003) has Add Virtual Directory. Be sure to have Read and Script permissions set for the application.
    • IIS 7 (Windows 2008 and Vista) has Add Application with no additional options required to be set.
  7. Open the Sample Application in your browser using the URL, http://sp-machine.domain/SampleApp
  8. Click the IDP Initiated SSO link to perform identity provider-initiated single sign-on.
  9. Enter the appropriate user credentials.

    The OpenSSO user demo with a password of changeit will work. After a successful authentication, the fedletapplication.aspx page is displayed with access to the AuthnResponse information.

To Integrate the ASP.NET Fedlet with an Existing Application

The Sample Application demonstrates how to retrieve attributes and subject information from the SAMLv2 assertion in an AuthnResponse object. The following code can be integrated in custom applications to do the same. It is expected to be placed in an aspx page or ASP.NET URI to receive the authentication response in an HTTP-POST binding.

       AuthnResponse authnResponse = null; 
       try 
       { 
           ServiceProviderUtility spu = new ServiceProviderUtility(Context); 
           authnResponse = spu.GetAuthnResponse(Request); 
       } 
       catch (Saml2Exception se) 
       { 
           // invalid AuthnResponse received 
       } 
       catch (ServiceProviderUtilityException spue) 
       { 
           // issues with deployment (reading metadata) 
       } 

More information on the Fedlet is in The Fedlet Cyrkle of Information.

And now for another Sign of the Times with the Belle Stars.

About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today