Sunday Nov 15, 2009

Configuring Identity Manager Password Reset with OpenSSO NOW

The following information concerns extending the end user password reset or forgot password feature to include Identity Manager 8.1.0.5 to be released sometime in October. (I wrote this weeks ago but forgot to publish it.) In a deployment that has both products integrated, a user needs the option to change or reset a configured password. To allow for identification, challenge questions should be configured for each user account. Unless these questions are answered correctly, this behavior will not be allowed. The flow diagram below details the process. (Right click it to open it full size in a new tab or window.)

To enable this feature, you will need to configure OpenSSO and then test the configurations. The configurations will work if the user has already configured challenge questions and answers or whether the user needs to configure challenge questions and answers now. The following sections have more information.

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 Forgot Password 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 Forgot Password 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 forgot_pwd.html on the OpenSSO web site.
    The URL in one section of this page that ends .../idm/authutil/questionLogin.jsp?accountId= links to the Identity Manager JSP that will be displayed if the user does not have challenge questions configured. Replace the beginning of this URL (http://am-v490-01.red.iplanet.com:6480/idm/authutil/questionLogin.jsp?accountId= in the file) with the specifics of 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 the glassfish-home/domains/your-domain/generated/ directory.
  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 directory 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.

Test The Configurations

  1. Access an Identity Manager URL.
    You will be redirected to the OpenSSO login page.
  2. Enter a username and click the "Forgot Password" button.
    You will be redirected to the Identity Manager questionLogin.jsp.
  3. Enter answers to the challenge questions and click the "Login" button.
    You will be redirected to second page.
  4. Enter your new password on this second page.
    This is a temporary password you would've received from contacting the help desk. See the process flow diagram above.
  5. Select the option to update all resource accounts.
    Ensure that both the Identity Manager and OpenSSO resources are selected.
  6. Select the option in the column "Forgot Old Password?" for the OpenSSO Resource.
  7. Click the "Change Password" button.
    The password is now changed. Use the new password next time you log in.

I had to come up with a video for this older post so I just clicked around and found this Queen video, Don't Stop Me Now. I saw this tour at MSG - leather and all!

Tuesday Oct 13, 2009

Cool Changes to the OpenSSO Console

Some new attributes have been added to the OpenSSO Administration Console and are available now in the nightly builds.
  1. Prompt User for Old Password is a flag that will do just that - add a text field to the Change Password page that would require a user to enter the old password when changing it. The attribute is located under the top level Configuration tab. Underneath the Configuration tab, click the Console tab and then the Administration link. It is in the Realm Attributes section.
    If not checked, the old password will not be required. This is the default behavior. If checked, the behavior is dependent upon whom is changing the password: the administrator or the end user.

    • If an administrator is changing the password for the end user, the old password is not required. The Prompt User for Old Password text field will be grayed out and the password will be changed by calling the getIdentity method in com.sun.identity.idm.IdUtils.
    • If the end user is changing the password on their own, the old password will be required. The Prompt User for Old Password text field will be enabled and, after it has been entered, the password will be changed by calling the changePasswordmethod in com.sun.identity.idm.AMIdentity.
  2. Requested Key Type allows you to define the key system used by the STS Client profile defined; for example, the default SecurityTokenService. The attribute is located under the top level Access Control tab. Under the Access Control tab, click the appropriate realm link, then the Agents tab and then the STS Client tab. Click the name of the profile you are configuring to see the attribute under the Security section.
    You can choose Public Key (two keys are used - one to encrypt the data and one to decrypt the data) or Symmetric Key (one key is used to encrypt and decrypt the data).
  3. A SAML Configuration section has been added to the STS Client and Web Service Client agent profiles to help configure the SAMLv2 protocol. (The section already exists for the Web Service Provider agent profile.) The section is located under the top level Access Control tab. Under the Access Control tab, click the appropriate realm link, then the Agents tab and then the STS Client tab or the Web Service Client tab. Click the name of the profile you are configuring to see the SAML Configuration section link. The section includes the following attributes.

    • SAML Attribute Mapping: This configuration maps the SAML attribute in an assertion from an incoming web service request to an attribute that would be fetched from either an authenticated OpenSSO SSOToken or the configured OpenSSO identity data store. The SAML attribute would be placed in the Attribute Statement created by the Security Token Service for a web service provider. The format is SAML_attr_name=OSSO_attr_name where SAML_attr_name is the SAML attribute name in the assertion from an incoming web service request and OSSO_attr_name is the attribute name that is fetched from OpenSSO.
    • SAML NameID Mapper Plugin: This attribute defines the NameID mapper plug-in class to be used for SAML account mapping.
    • SAML Attributes Namespace: This attribute defines the name space used to qualify SAML attributes and elements.
    • Include Memberships: If enabled, this attribute specifies that the principal's membership data must be included in the assertion as a SAML attribute.

Now here's Cool Change from Little River Band.

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.

Monday Feb 09, 2009

Deployment Example 2: SAE Expanded, Not Reduced

Some additional procedures have been made to the Secure Attribute Exchange (aka Virtual Federation) section of Deployment Example 2: SAML v2 Using Sun OpenSSO Enterprise 8.0. The section has been reorganized and changes made to 13.2 and 13.3, the identity provider and service provider configuration sections. You can see the new HTML version here on docs.sun.com tomorrow but you can download the new PDF from OpenSSO now.

And since SuperPat scoffs at my description of The Enemy as being old-school punk (pulling out his Coventry cred, no less) I decided to embed some real punk I happen to see back in the day (pulling out my CBGB cred, no less) from the Dead Boys. Check out Sonic Reducer.

Monday Dec 01, 2008

Stopping and Starting an External Configuration Data Store is Björn Again

Thanks to OpenSSO members Christopher and Michel for this information.
OpenSSO uses an LDAP server for persistence of its configuration data so the LDAP server that contains this configuration data must be available when OpenSSO is running. After a default installation OpenDS, which is embedded with OpenSSO, will stop and start as OpenSSO does. If OpenSSO is installed pointing to an instance of Directory Server for its configuration data, Directory Server needs to be stopped and started on its own. The best way to do this is to stop the underlying OpenSSO web container first and Directory Server second - reversing the order for the imminent restart. This insures that the configuration data is always available for the OpenSSO web application.

That said, I've noticed a few people (externally and internally) asking about an Invalid Domain - No such Organization found error that is displayed when attempting to log in to the console using the default URL (http://web-server-host:port/opensso/UI/Login) after restarting an instance of Directory Server 5.2 configured as the OpenSSO configuration data store. If you see this error message, do the following:
  1. Login to the OpenSSO console at http://web-server-host:port/opensso/UI/Login?org=LDAP-DN-root.
  2. Under the Access Control tab, click the / (Top-level Realm).
  3. Add another host name to the Realm/DNS Alias property of the / (Top-level Realm) and click Save.
    The information will be removed so MacGuffin text is fine.
  4. Restart the deployment as previously detailed.
  5. Login to the OpenSSO console using the default URL and remove the host name you just added.
This workaround forces OpenSSO to export the Realm/DNS Alias values to the external Directory Server. The following search returns zero results before the workaround and should return one result after it.

SRCH base="ou=services,DN" scope=2 filter="(|(&(objectClass=sunRealmService)(&(|(sunxmlkeyvalue=sunidentityrepositoryservice-sunOrganizationAliases=hostname.site.com)(sunxmlkeyvalue=sunOrganizationAliases=hostname.site.com))))(&(objectClass=sunServiceComponent)(&(|(sunxmlkeyvalue=sunidentityrepositoryservice-sunOrganizationAliases=hostname.site.com)(sunxmlkeyvalue=sunOrganizationAliases=hostname.site.com)))))" attrs="o"

While you're waiting for the restart, enjoy Stop, the ABBA-esque version of the Erasure song by Björn Again.

Friday Oct 31, 2008

Test the OpenSSO Deployment Documents

I know there are people out there who have been wondering where my blog entries have been for the last two and a half months - and to both of you I say: I've been assiduously (thanks for the word, Alan) working on two deployment books for release with Sun OpenSSO Enterprise 8.0. Here are links to the PDFs - test them out and let me know what you think. But all that work has made me drowsy so I'm taking two weeks off now. In the meantime, enjoy As We Stumble Along featuring Robert Martin as Man in Chair and Beth Leavel as The Drowsy Chaperone. You gotta love a song that rhymes stumble with...parumble?

Monday Sep 08, 2008

Tired of Toein' the OpenSSO 8.0 Technical Overview

I've been in major crunch mode recently - writing the documentation that will be released with Sun OpenSSO Enterprise 8.0. Unfortunately, that doesn't leave much time for blogging. Well just to let you know that I am still here, the Technical Overview is just about 96% finished. (I used a mathematical formula to get that percentage.) It has been posted to the OpenSSO EA Doc Page; check it out as well as the other not-ready-for-prime-time guides to understanding and using OpenSSO.

If you have any comments/issues with anything you read in the Technical Overview (or any of the EA docs) leave your comments below or just email users@opensso.dev.java.net. I'll make sure the correct writer gets the information. Thanks in advance.

Currently I'm working with engineer extraordinaire Anant on the update of a deployment example in which there are procedures for installing, configuring and/or implementing OpenSSO, Directory Server, web containers, policy agents, load balancers and session failover. Look for an EA version of this on the OpenSSO EA Doc Page next week.

Following the culmination of that book, I'll be working with yet another extraordinary engineer, Wei, on a deployment example for implementing federation and SAMLv2 communications. That won't be up before next month but I can see you're salivating now. We'll hurry it up.

In the meantime, check out Rocky Burnette's hit from 1980, because sometimes we all get Tired of Toein' the Line.

Recognize me without the red glasses? I still wear them sometimes.

Oh vez mear. Time flies when having fun!

Saturday Aug 23, 2008

Duffy, Lulu and Sub Realm Policy Administration in OpenSSO

Let's assume you have a top level realm named /opensso (because everybody has at one point). Under opensso create a sub realm called test. In the test sub realm, create a new user named usr1. Now create a new group, grp1, and assign read and write privileges for policy data to grp1 and assign usr1 to grp1.

Log in to the test sub realm using the URL http://fdqn:port/opensso/UI/Login?realm=test and the name and password for usr1. The administration pages for the sub realm are displayed in order to manage its policy data. If you use the URL http://fdqn:port/opensso/UI/Login, the user's page is displayed in order to manage the user profile. This insures the following:

  • usr1 will not have permission to manage policy data of the parent realm (opensso or any peer sub realms.
  • usr1 will have permissions to manage policy data of the test sub realm and any realms created beneath it.

Now, let's take the Duffy/Lulu taste test. First view the video for Mercy as performed by Duffy in 2008.

Now compare the voice you just heard to that of Lulu singing The Boat That I Row in 1968. Pretty close and forty years earlier.

Sunday Aug 17, 2008

Sampling the OpenSSO Samples and Yazoo

There are three types of samples included with OpenSSO.

  1. Server samples are included with the OpenSSO WAR. The samples can be accessed by appending /uri/samples to the OpenSSO server URL and entering it in the Location bar of a browser; by default, this would be http://hostname.domain:8080/opensso/samples. The samples include authentication, Liberty ID-FF, SAMLv2, and multi-federation protocol. I haven't checked them out yet.
  2. The Client SDK samples are located in the opensso-client-jdk15.war inside the opensso-client.zip. More information is in these entries:

  3. Command line interface samples are located in the sdk directory inside the unzipped opensso-client.zip. See OpenSSO Client SDK: Command-line Samples for more information.
  4. And since we are talking samples, let's listen to a moment in time: the song that has one of the most used samples in music history. In 1982, Vince Clarke says something funny and Alison Moyet laughs during the recording of the Yaz song Situation and they decide to keep it in the recording. I have heard that laugh sampled on a huge number of remixes and new songs over the last 25 years but there ain't nothing like hearing it as originally intended.

    I saw them at the Paramount Theater in Oakland, CA on July 7, 2008. What a show!

Tuesday Aug 12, 2008

SOA's Readers' Choice Awards and Sia's Buttons

You can now vote online for the SOA World Magazine 2008 Readers' Choice Awards which recognizes, and I quote, excellence in the software, solutions, or services provided by the industry's top vendors. Readers can cast their votes until November 8, 2008.

That was SOA. Now here is Sia performing her song Buttons live on Jimmy Kimmel.

Click here for the official music video which is just as...um...interesting...as the live performance.

Monday Aug 11, 2008

Turning Old Command Line Interfaces into New OpenSSO Command Line Interface

A number of command line interfaces originally developed for the products that have been integrated into OpenSSO have been EOL'ed. So here is some information on the new commands and options that can be used instead.

amadmin

Although the legacy command line interface amadmin is still bundled with OpenSSO, certain LIberty Alliance Project Identity-Federation Framework (Liberty ID-FF) related options are no longer supported because of a change in the metadata format. Use the following ssoadm commands to import and export metadata. Be sure to append --spec idff to the command.

amadmin Optionssoadm Command
-g|--importimport-entity
-o|--exportexport-entity

saml2meta

The command line interface saml2meta (originally developed for the Sun Java System SAMLv2 Plug-in for Federation Services) is not supported in OpenSSO. Use the corresponding ssoadm commands instead. Note that some of the new commands must have --spec saml2 appended.

saml2meta Optionssoadm Command
importimport-entity with --spec saml2 option
exportexport-entity with --spec saml2 option
templatecreate-metadata-templ with --spec saml2 option
deletedelete-entity with --spec saml2 option
listlist-entities with --spec saml2 option
cotcreatecreate-cot
cotdeletedelete-cot
cotaddadd-cot-member
cotremoveremove-cot-member
cotmemberlist-cot-members
cotlistlist-cots

saml2bulkfed

The command line interfaces saml2bulkfed (originally developed for the Sun Java System SAMLv2 Plug-in for Federation Services) is not supported in OpenSSO. Use the following ssoadm commands for SAMLv2 bulk federation. Be sure to append --spec saml2 to the command.
  • do-bulk-federation performs bulk federation.
  • import-bulk-fed-data imports the bulk federation data generated by the do-bulk-federation command.

ambulkfed

The command line interface ambulkfed (originally developed for Access Manager to bulk federate using the Liberty ID-FF protocol) is not supported in OpenSSO either. The ssoadm commands that take the place of the SAMLv2 bulk federation CLI (above) can also be used for Liberty ID-FF bulk federation by appending --spec idff to the command rather than --spec saml2.

And now some new music (on this side of the pond anyway) from Alison Moyet. The Turn was just released in North America and features the single, A Guy Like You.

Friday Aug 08, 2008

HELP! Review OpenSSO During Early Access

Sun is now soliciting feedback regarding the Early Access download (Express Build 5) of the OpenSSO software. Here's the official marketing shpiel:

The OpenSSO Project is soliciting feedback on their Early Access Build -- OpenSSO Express Build 5. With the release of this build, community members now have the opportunity to participate in the Early Access (EA) program for Sun's next commercial offering. Review the Early Access documentation and hammer away at Express Build 5! Send your EA feedback to opensso.eafeedback@dev.java.net so we can make the product perfect. Thanks in advance!

Now here's my shpiel - or should I say the Beatles shpiel in my stead:

But who would embed the Beatles HELP without also embedding the Bananarama version featuring Lananeeneenoonoo (or Dawn French, Jennifer Saunders and Kathy Burke).

And they did it all for others.

Just like all of us. Thanks.

Thursday Aug 07, 2008

Discovering and Setting (On Fire?) Preferred Identity Providers

Here is additional information on the Identity Provider Discovery Service. Discovering the SAMLv2 IDP Discovery Service and the Discovery LP has general information and the procedure for setting up and testing the Identity Provider Discovery Service. Here is the process to set a preferred identity provider.

NOTE: spSSOInit.jsp is used to initiate single sign-on from the service provider side. On receiving a request for access, spSSOInit.jsp verifies that the required parameters are defined. See the Sun Java System SAML v2 Plug-in for Federation Services User's Guide for more information.

  1. A user accesses spSSOInit.jsp to initiate single sign-on on the service provider side, and passes to it the value of the idpEntityID parameter.

    The value is the entity identifier of the identity provider to which the request should be sent.
  2. The service provider retrieves the identity provider's single sign-on service URL using the value of the idpEntityID and redirects the user to it.
  3. Assuming the user is not authenticated, the identity provider prompts the user for credentials.

    >If the Identity Provider Discovery Service is configured, the user will be redirected to the Identity Provider Discovery Service Writer Service URL with the identity provider information. The Discovery Service Writer Service URL sets the common domain cookie.
  4. The Identity Provider Discovery Service Writer Service URL sets the cookie with the identity provider information and redirects the user back to the identity provider's single sign-on service URL.

    The preferred identity provider is now set.
  5. The identity provider's single sign-on service URL completes the single sign-on process.

Here is the process when discovering a preferred identity provider.

  1. A user accesses spSSOInit.jsp to initiate single sign-on on the service provider side and one of the following occurs:

    • If the value of idpEntityID is passed, the identity provider will be contacted directly. See the previous procedure.
    • If there is no value for idpEntityID but the Identity Provider Discovery Service is configured, the user will be directed to the Reader Service URL to retrieve the preferred identity provider's entity identifier. In this case, the RelayState parameter points back to spSSOInit.jsp.
  2. The Identity Provider Discovery Service Reader Service URL checks for an identity provider discovery cookie and, if set, extracts the preferred identity provider, returning the information as a query parameter in the relay state URL.
  3. spSSOInit.jsp checks for the preferred identity provider in the returned URL.

    • If the preferred identity provider is set, the request is sent to it for single sign-on.
    • If the preferred identity provider is not set, an error is displayed stating this.
Whewww, that was hot! But not as hot as the 5000 Volts song (with an uncredited Tina Charles singing lead), I'm On Fire. Was there ever anything as remotely entertaining as disco? (Don't answer that if you are going to be mean.)

Sunday Aug 03, 2008

What Are You Doing The RESTful of Your Life?

I was looking for information on REST and found this great article on developers.sun.com. Check it out if you need to get REST.

And here is Miss Peggy Lee singing What Are You Doing The Rest If Your LIfe?

Thursday Mar 06, 2008

The One-Level Wildcard for Policy Logic

UPDATE-3/21/08: The one-level wildcard is currently only available to the J2EE agents - not the web agents.

After putting together the couplet entries on policy logic in OpenSSO and wildcard matches in policy agents, I received an email from Bhavna, one of Sun's Federated Access Manager engineering gurus, who wrote - and I cut and paste:

good addition. You might want to add some information on one level wild card too which, by default, is "-\*-"
unfortunately we don't have much documentation on it.

NOTE: I'm thankful for that last sentence myself.

Well here is the scoop that turns our couplet into a triplet. The one-level wildcard was introduced in Sun Java System Access Manager 7.1. The wildcard itself is -\*- and it matches only the level for which it stands without crossing delimiter boundaries. A policy can include the one-level wildcard in resource names to allow and deny access. For example, if you allow access to http://www.sun.com/b/-\*-/d in a policy definition then access to http://www.sun.com/b/c/d will be allowed but access to http://www.sun.com/b/c/e/d will be denied. -\*- would match any character but only at the defined level.

And, in honor of all the gurus at Sun, here's a music clip from a very funny and sweet movie called The Guru. It's American-financed but filmed in the Bollywood-style. (Any suggestions on some Bollywood movies I should see would be appreciated.) The song is called Chori Chori which from my perusal on the internet means "secretly".

Once you've met The Guru, love will never sound the same.

Tuesday Jan 29, 2008

Coupla Access Manager 7.1 Tips

For those using Access Manager 7.1 here are a coupla things you might want to know about.

  • Access Manager 7.1 can be installed in one of two modes: realm or legacy. So after installation how do you determine if Access Manager is running in realm mode or legacy mode?

    Type the following URL into the Location window of your browser and hit Enter.

    protocol://FQDN:portnumber/amserver/SMSServlet?method=isRealmEnabled

    where

    FQDN is the host name and domain of the machine on which the product was installed. If the server returns true, Access Manager is running in realm mode; otherwise, it's running in legacy mode.
  • If the host name and/or domain name of the machine on which Access Manager is running changes, this change needs to be reflected in a number of configuration files. This recently published technical note, Host Name Changes in a Sun Java System Access Manager 7.1 WAR Deployment explains it all for you.

And while we're at it here are a coupla versions of the same classic song, Jolene. The first video is a version by a coupla people in a little band called The White Stripes. The second is a version by the song's writer, Dolly Parton (who has a coupla - no I won't go there even though she does in the video). Take your pick or watch both.

I mean both videos.

Tuesday Jan 15, 2008

OpenSSO & OpenDS Sitting in a Tree, K-I-S-S...

In case you hadn't noticed, OpenSSO build 2 (the soon-to-be christened Federated Access Manager) now stores its configuration data in a data store rather than a flat file. OpenDS is the new embedded configuration store, replacing the previous flat file implementation where configuration files were stored...um...all over the place (okay, there was sms). Now, OpenDS is installed with OpenSSO and the configuration data is stored.

The installed version of OpenDS is not complete (for example, the bin scripts have been removed to make the opensso.war as small as possible). But you can always download opends.zip, explode it and point the script parameters to the configuration directory (config_dir_specified_in_configurator/opends). This will most probably change as the OpenDS builds stabilize.

Some things based on this move have already changed. For example, famadm is a utility that lets you manage your OpenSSO installation from the command line. When famadm was developed you needed to point to AMConfig.properties during setup. But from OpenSSO build 2, AMConfig.properties is now stored in an instance of OpenDS. So during setup you need to point famadm to a bootstrap file named, appropriately enough, bootstrap. bootstrap is located under the directory defined during configuration as the Configuration Directory.

The concept is that the CLI will read the bootstrap file, contact OpenDS, fetch the appropriate properties, and bootstrap itself.

So to bring it full-circle, and to tout what I will be doing on my long holiday weekend (which starts as soon as I publish this entry), here's KISS.

Thursday Jan 03, 2008

REVIEW: Client SDK chapter FAM8 Developer's Guide

I have posted a review PDF of the Client SDK chapter for the Federated Access Manager 8 Developer's Guide and I'd love to hear what you think.

https://opensso.dev.java.net/public/use/docs/opensso/pdf/clientsdk.pdf

And since I am being societally forced to say Happy New Year (society is holding my fingers to the keypads), I'll do it with a catchy little disco anthem from The Ritchie Family.

Monday Dec 17, 2007

SSO Sample: OpenSSO Client SDK

The Single Sign-On Token Verification Sample validates an SSOToken and then displays the user profile associated with it. This sample is accesible from the Client SDK-Samples page.

You must log in to the OpenSSO console in order to run this sample. Once you are logged in, click Click and the user profile associated with the SSOToken you received after authentication is displayed. I logged in as the default administrator, amadmin, and received the following profile:

SSOToken host name: 127.0.0.1
SSOToken Principal name: id=amadmin,ou=user,dc=opensso,dc=java,dc=net
Authentication type used: DataStore
IPAddress of the host: 127.0.0.1
SSO Token validation test succeeded
The token id is AQIC5wM2LY4SfcxaVucZ3AN669OG0Nzq+dA52vuEuaMIQhU=@AAJTSQACMDE=#
Property: Company: Sun Microsystems
Property: Country: USA
User Attributes: {inetUserStatus=[Active], dn=[uid=amAdmin,ou=people,dc=opensso,dc=java,dc=net], roles=[Top-level Admin Role]}

NOTE: One caveat I encountered was that the sample will not work if the machine name and host don't match in the OpenSSO server and the sample SDK WARs. I had installed OpenSSO on my machine, develop2.orange.sunlab.com. The client sample WAR was automatically deployed on localhost - the same machine. But the sample did not work until I manually changed localhost to develop2.orange.sunlab.com in the browser location window.

The code included with this sample is SSOTokenSampleServlet.java and SampleTokenListener.java. These files serve as a basis for using the SSO API, demonstrating how you can create an SSO Token, call various methods from the token, set up an event listener and get notified on event changes.

Wednesday Dec 12, 2007

User and Policy Samples: OpenSSO Client SDK

Now that I've gotten through the installation of the OpenSSO Client SDK sample WAR and it's Service Configuration Servlet sample, let's take a look at other Client SDK samples. The next one on the Client SDK - Samples list is the User Profile (Attributes) Sample Servlet.

The UserProfileServlet.java sample code retrieves and displays the profile that corresponds to the user ID entered in the Username text box. I created a user profile aaaa, entered the ID and password in the text fields and, voila, straight forward and it worked.

Note the email address, given name and other information retreived.

The Policy Evaluator Client Sample Servlet retrieves from the Policy Service a policy decision that would be passed to a web agent for enforcement. I created a policy using the OpenSSO server for the resource http://www.sun.com:80 with a GET allow and POST deny rule for all authenticated users on Fridays. PolicyClientServlet.java is the call on the client side that initiates the retrieval of the policy decision.

And while you're waiting for my follow-up entries on the SSO and command-line samples for the Client SDK, you might want to check out this video of Nellie McKay and learn how to do the dance that's sweeping the nation - come one everyone, 'do the Zombie'. It'll do you good.

Sunday Dec 09, 2007

Federated Access Manager 8.0 Roadmap and Features

I have been asked one particular question many times over the last few months and have been fudging my answer because way back when I wrote an entry that attempted to answer this question I was chastised by some muckety-mucks. On Friday, I was searching for some information and, lo and behold, found that Daniel Raskin, our relatively new marketing guru, had written a blog regarding the answer to the very same question I have been hesitating to answer: can you give me some information regarding FAM 8.0 roadmap and features? So, here are links to the blog entries that answer that question. Way to go, Daniel!

Federated Access Manager 8.0 -- The Overview (Part I)

Federated Access Manager 8.0 -- The Features (Part II)

On Saturday, I was searching for something fun to watch and found this clip of one of the all-time great comics, Totie Fields. Way to go, Totie!

Tuesday Dec 04, 2007

Updated OpenSSO FAQ

I took a moment last week to update the OpenSSO FAQ Center. The only question I have now is...

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