Tuesday Jan 12, 2010

Authenticating for the OpenSSO Entitlements Service REST Interfaces

This is part one of a four part series on the OpenSSO REST interfaces for the Entitlements Service. Part two is Listening for the OpenSSO Entitlements Service Using REST, part three is Evaluating OpenSSO Entitlements Using REST, and part four is Managing OpenSSO Entitlements Using REST.

The OpenSSO Entitlements Service provides fine grained access control. With the upcoming release of OpenSSO Express 9, RESTful interfaces (in the form of URLs) have been developed for the Entitlements Service. (Information on other OpenSSO RESTful interfaces can be found .)

Before using the Entitlements Service REST interfaces, the user making the calls needs to be authenticated and receive a session token identifier. Following authentication, this identifier must be hashed and encoded for input as a parameter value of the Entitlements Service REST URLs. The following sections have more information.

Authenticating to OpenSSO Before Using REST

Before making a REST call using one of the Entitlements Service URLs, the subject must authenticate to OpenSSO using the authenticate REST identity interface. This identity call, if successful, will get a session token identifier for the subject that will then be used as input for the Entitlements Service REST URLs. An example of the authenticate REST URL is:

http://www.example.com:8080/opensso/identity/authenticate?username=user1&password=changeme

NOTE: For this use, the authenticate URL should use HTTP POST because (the default) HTTP GET logs the user information which might be a security issue in some deployments.

This authenticate call would return a session token.id; for example:

token.id=AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=#

This session token.id needs to be set as the iPlanetDirectoryPro cookie.

iPlanetDirectoryPro=AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=#

Additionally, a SHA1-hashed and base64 encoded string needs to be generated from the value of the token.id. This encoded string, representing the user, will be passed as a parameter with every REST call.

Encoding the token.id

This procedure will generate a SHA1-hashed and base64 encoded string from the session token.id previously returned.
  1. Compile the Encoder.java code found on opensso.dev.java.net.

    javac Encoder.java
  2. Run the compiled Encoder to hash and encode the session token.id.

    java Encoder AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=

The Encoder returns a string such as vd6RXuEnYJl93VWftk9plOzAqfQ=. This string is a SHA1 hash that is also base64 encoded. It must be passed as a parameter with every REST call to indicate the subject; for example:

subject=vd6RXuEnYJl93VWftk9plOzAqfQ=

The actual information on the Entitlements Service REST interfaces will be forthcoming. (And this entry will make more sense. ;> ) It includes policy evaluation, privilege management and listener management REST interfaces. In the meantime, take the Rest of the Day Off from Neil Finn's 2001 album - Bowie-esque from his Heroes period.


Monday Jan 04, 2010

Happy New Year Authenticating to OpenSSO Monitoring Service

A monitoring framework based on the Java Dynamic Management Kit (JDMK) was introduced in OpenSSO Express Build 8. Access to OpenSSO's monitoring data may be via the HTTP, SNMP (Simple Network Management Protocol), or RMI (Remote Method Invocation) interfaces.

In OpenSSO Express Build 9 (and currently available in the nightly build), access to the Monitoring Service's HTTP interface has been modified to require authentication to access OpenSSO monitoring data through the HTTP interface. (An HTML Protocol Adaptor comes with the JDMK and is used to authenticate. See The HTML Protocol Adaptor for more information.)

The opensso_mon_auth file contains the name and password of the user (or users) with permission to log in and see the OpenSSO monitoring data. It is located in the /ConfigurationDirectory/install-URI/ directory created during the OpenSSO installation; by default, /opensso/opensso/opensso_mon_auth. The file initially contains the user demo with an encrypted value equal to the password changeit. This user can be replaced or additional users added to the file. Type any user identifier followed by a space and the encrypted value of the user's password. The user name is case-sensitive and the password must be encrypted using the ampassword command line tool. It is located in the ssoAdminTools.zip which is in the tools directory of the expanded opensso.zip. For more information see Installing the OpenSSO Enterprise Utilities and Scripts.

NOTE: The user in this file is not tied in any respect to the OpenSSO user data store. Authentication to the monitoring data using the HTML Protocol Adaptor is a separate authentication process from that of OpenSSO.

Now just a little wish from ABBA (and me, by proxy) for all to enjoy the new year and decade. Happy New Year from the Super Trouper LP - an acronym from many new years ago.

Tuesday Dec 08, 2009

Could It Be the OpenSSO OAuth Token Service?

An early access version of the OpenSSO OAuth Token Service is now available in the nightly builds. OAuth provides a method for exchanging user credentials for an access token. This token, authorized by a user, grants access to private resources from the user's account on one service provider site to a second, consumer site - without having to divulge identity information (including user name and password). The OpenSSO OAuth Token Service supports parts of the OAuth Core 1.0 Specifications including consumer registration, Request Token requests, Request Token authorizations, and Access Tokens. The following sections contain information on the OpenSSO OAuth Token Service as it stands today.

OpenSSO OAuth Token Service Overview

An OAuth consumer site needs to register with the OpenSSO OAuth Token Service used by the service provider site before it can request OAuth tokens. Once registration has been successful, the registered consumer site can get an unauthorized OAuth Request Token on behalf of a user. The user agent (browser) will be redirected to the service provider site where the user authenticates and is then asked to authorize or revoke the Request Token. (The user is asked to enter a user name and password.) After a successful authorization, the user agent is redirected back to the consumer site with an authorized Request Token. The consumer site then sends a request to the service provider site for an Access Token that enables the consumer site to access the resources on the service provider site. More detailed information is in the following sections:

Registering An OAuth Consumer Site

An OAuth service provider requires each consumer site to register, and get a consumer key, before being able to make OAuth requests. When the Service Consumers Metadata Management page is displayed by accessing http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/oauth/index.jsp, enter a Service Consumer Name and an optional Service Consumer URI. Click the Register button to complete the registration. Upon successful registration, the OAuth Token Service returns a response similar to the following.
Service Consumer registered.
consumer_key=http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/resources/1/oauth/consumer/7faf3762e2b048e2b4998f3e65c376b4
consumer_secret=5fe61f1ad7f445f9b63793916c561dd7
The consumer key and consumer secret should be kept in a secure location as they will be needed to identify this particular consumer.

You can also use the Service Consumers Metadata Management page to delete a registered consumer site. Enter the consumer key (returned when the consumer site was originally registered) of the consumer site to be deleted in the Service Consumer Key field and click Delete to remove it.

Requesting User Authorization as an OAuth Request Token

An unauthorized OAuth Request Token is used by a consumer site to get approval from a user to access resources from the user's service provider account. A registered consumer site can request an unauthorized Request Token from http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/resources/1/oauth/get_request_token. The request should use HTTP POST, must be signed, and should contain the following parameters:
  • oauth_consumer_key is the consumer key returned when the consumer site was originally registered with the OAuth service provider.
  • oauth_signature_method is the signature method used by the consumer site to sign the request. All Request Token requests must be signed by the consumer site and verified by the service provider. Supported signature methods are HMAC-SHA1 and PLAINTEXT.
  • oauth_signature is the generated signature. The consumer site declares a signature method, generates a signature, and stores it as the value of this parameter. The service provider then verifies the signature as specified by each method.
  • oauth_timestamp is the timestamp. Unless otherwise specified, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. It must be a positive integer and equal or greater than the timestamp used in previous requests.
  • oauth_nonce is a random string, generated for each request by the consumer site, that is unique for all requests with a particular timestamp.
  • oauth_version is an optional parameter that defines the OAuth specification version being used. If defined, the value must be 1.0.
The response to the Request Token request should contain the following parameters:
  • oauth_token is the Request Token.
  • oauth_token_secret is the Token Secret used for verification.
The user will need to authorize this request before an Access Token is granted.

Authorizing An OAuth Request Token

A user authorizes an OAuth Request Token through redirection to the OpenSSO OAuth Token Service Authorization Console at http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/oauth/userconsole.jsp. If not yet authenticated by OpenSSO, the user will be redirected to the OpenSSO login page. Once the user successfully authenticates, the OpenSSO OAuth Token Service Authorization Console is displayed with the choice to authorize or revoke the Request Token request.

The request should use HTTP GET (in many cases, the user is redirected to this URL by the consumer site) and should contain the following parameters:
  • oauth_token is the Request Token to be authorized.
  • oauth_callback is the URL that the OpenSSO OAuth Token Service will use to redirect the user back to the consumer site after user authorization is complete.
Following a successful OAuth authorization, the Oauth Token Service constructs an HTTP GET request URL to redirect the user to the oauth_callback URL with the authorized Request Token as the value of oauth_token.

Requesting an OAuth Access Token

An authorized Request Token is used to request an OAuth Access Token which will allow the consumer site access to the user's service provider account. A registered consumer site can request an Access Token from http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/resources/1/oauth/get_access_token. The request should use HTTP POST, must be signed, and should contain the following parameters:
  • oauth_consumer_key is the consumer key returned when the consumer site was originally registered with the OAuth service provider.
  • oauth_token is the authorized Request Token.
  • oauth_signature_method is the signature method used by the consumer site to sign the request. All Request Token requests must be signed by the consumer site and verified by the service provider. Supported signature methods are HMAC-SHA1 and PLAINTEXT.
  • oauth_signature is the generated signature. The consumer site declares a signature method, generates a signature, and stores it as the value of this parameter. The service provider then verifies the signature as specified by each method.
  • oauth_timestamp is the timestamp. Unless otherwise specified, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. It must be a positive integer and equal or greater than the timestamp used in previous requests.
  • oauth_nonce is a random string, generated for each request by the consumer site, that is unique for all requests with a particular timestamp.
  • oauth_version is an optional parameter that defines the OAuth specification version being used. If defined, the value must be 1.0.
The response to the Access Token request should contain the following parameters:
  • oauth_token is the Access Token.
  • oauth_token_secret is the Token Secret used for verification.
Using the OAuth Token Service Sample

OpenSSO has an OAuth Token Service sample using the Stock Service and Stock Client sample code. The files are available in the OpenSSO source code or in a ZIP archive I put together and uploaded to the OpenSSO site. Refer to the included README file for details. It's pretty easy to run through.

And now enjoy this video of the Queen of Disco, Donna Summer, performing Could It Be Magic LIVE. Remember when singers actually used their vocal chords in live performances?

Wednesday Nov 11, 2009

True to Enable Resource Authentication for OpenSSO Policy Agents

The new resource authentication feature (as documented Resource Authentication Type in OpenSSO Express 8) can also be enabled for deployments that use OpenSSO policy agents - either Web Agents or J2EE Agents. To enable resource authentication, a URL in the agent profile must be modified by appending to it the resource=true query parameter. The attribute that contains this URL is dependent upon whether the policy agent is configured in Cross Domain SSO (CDSSO) or not.

The procedure requires appending the "resource=true" query parameter to the "OpenSSO Login URL" or "CDSSO Servlet URL" field as follows:
  1. Log into the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the name of the appropriate realm.
  4. Click the Agents tab.
  5. Click the appropriate agent tab (Web or J2EE).
  6. Click the name of the agent profile to modify.
  7. Choose the appropriate sub step based on whether the agent is configured in CDSSO mode or not.

    • For an agent running in CDSSO mode, click the SSO tab and append resource=true to the existing value of the CDSSO Servlet URL attribute. For example, http://opensso.sun.com:8080/opensso/cdcservlet?resource=true.
    • For an agent NOT running in CDSSO mode, click the OpenSSO Services tab and append resource=true to the existing value of the OpenSSO Login URL attribute. For example, http://opensso.sun.com:8080/opensso/UI/Login?resource=true.

As Spandau Ballet once sang so beautifully, it's True.

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.

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!

Tuesday May 05, 2009

WIKI COMMUNITY REVIEW: Managing OpenSSO Authentication

Feel free to click on over to the OpenSSO Resource Center wiki and review the articles listed on the Managing Authentication page. This is the first chapter to be ported from the Administration Guide on docs.sun.com. The material has been rewritten to include more information and to remove information that is no longer relevant.

Leave your comments here or as comments on the Resource Center page.

But if you're not on the wiki you should be...um...with the great Kirsty MacColl. Here's her video, He's On The Beach. Pop perfection!

Friday May 01, 2009

Romanticizing the OpenSSO WSSAuth Authentication Module

The WS-Security specifies the Username Token Profile for providing basic authentication information. The profile describes how the UsernameToken element can be used as a means for communicating a user identifier and password between a web service provider (WSP) and web service client (WSC). The OpenSSO WSSAuth authentication module validates the credentials presented by the WSC using the UsernameToken profile.

The UsernameToken profile contains an element to present a hash of the user's password - the PasswordDigest element. Using this element adds security as the password is not exposed as clear text. The following steps show how to configure for authentication using the Username Token profile with a one way hash password.
  1. Login into the OpenSSO console as administrator.
  2. Navigate to Access Control -> / (Top Level Realm) -> Agents -> Web Service Client -> wsc
  3. Select UserName Token as the value of Security Mechanism.
    This uses the PasswordDigest option.
  4. Enable User Authentication Required to generate a user token.
  5. Change the Name and Password values for the Credential for User Token.
    This attribute contains the shared secrets used by the WSC to generate a user token. The password should be the same as the hashed password stored in the OpenSSO configuration data store. Use ldapsearch if the data store is Directory Server. NOTE: This step is for demonstration purposes only. In real deployments, the WSC and WSP would have a common agreement about their password storage policy.
  6. Navigate to Access Control -> / (Top Level Realm) -> Authentication.
  7. Create a new authentication chain named wssauthchain.
    See Configuring an Authentication Process Using the OpenSSO Enterprise Console.
  8. Click wssauthchain in the list of authentication chains.
  9. Add WSSAuth as the required Authentication Mechanism and click Save.
  10. Navigate to Access Control -> / (Top Level Realm) -> Agents -> Web Service Provider -> wsp
  11. Select UserName Token as the value of Security Mechanism and wssauthchain as the authentication chain.
  12. Click Save.

To test the configurations, use the stock quote sample included with the Web Services Security Agent. After attempting to access the sample's main page, the user is redirected to OpenSSO for authentication. After successfully authenticating, the user is redirected back to the main page. When the user clicks the Get Quote button, stock quote values are displayed and the authentication mechanism used is displayed; in this case, Username Token with digest option. Changing the security mechanism would result in the new security mechanism being displayed. When logging is enabled, the OpenSSO logs would also have the appropriate tokens.

More romanticizing with Combo Audio performing the indy version of their tune, Romanticide for this video cover. I thought it was the real deal because the 7" single I owned back then had no band picture. Still a great tune.

Unlike the version they rerecorded after signing with a major label. This cleaner version is okay but not the bomb that was dropped when they released the original. But at least there's a video!

Thursday Jan 15, 2009

More, More, More Custom OpenSSO Authentication Modules

OpenSSO Enterprise provides the com.sun.identity.authentication.spi package to write Java-based authentication modules and plug them into the Authentication Service framework, allowing proprietary authentication providers to be managed using the OpenSSO Enterprise console. The authentication module is created using the abstract com.sun.identity.authentication.spi.AMLoginModule class which implements the JAAS LoginModule class.

com.sun.identity.authentication.spi.AMLoginModule provides methods to access the Authentication Service and the authentication module's callback requirements file. Once created, a custom authentication module can be added to the list of authentication modules displayed by the OpenSSO Enterprise console. Use the following list of procedures as a checklist to create and integrate a custom authentication odule into OpenSSO.

  1. Create a callback requirements file for the new authentication module.
    The authentication module's callback requirements file is written in XML and defines the module's authentication requirements and login state information. The parameters in this file automatically and dynamically customize the authentication module's user interface in the form of login pages that provide the means to initiate, construct and send credential requests to the Distributed Authentication User Interface. When an authentication process is invoked, the values nested in the Callbacks element of the module's configuration properties file are used to generate login screens. The module controls the login process, and determines each concurring screen. The callback requirements file included with OpenSSO and the corresponding DTD (Auth_Module_Properties.dtd) can be found in the source code and used as a template for creating a new one.
  2. Implement a Principal class.
    Write a class which implements java.security.Principal to represent the entity requesting authentication. For example, the constructor takes the username as an argument. If authentication is successful, the module will return this principal to the Authentication Service which populates the login state and session token with the information representing the user.
  3. Create a service file for the new authentication module.
    The authentication module's service file is written in XML and imported to OpenSSO to allow the management of its attributes using the OpenSSO console. The name of the service file follows the format amAuthmodulename.xml (for example, amAuthSafeWord.xml or amAuthLDAP.xml). The service files included with OpenSSO and the corresponding DTD (sms.dtd) can be found in the source code and used as a template for creating a new one. You can also cut, paste and modify the following template.
  4. <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ServicesConfiguration
    PUBLIC "=//iPlanet//Service Management Services (SMS) 1.0 DTD//EN"
    "jar://com/sun/identity/sm/sms.dtd">
    <ServicesConfiguration>
    <Service name="iPlanetAMAuthMYMODULEAuthService" version="1.0">
    <Schema
    serviceHierarchy="/DSAMEConfig/authentication/iPlanetAMAuthMYMODULEAuthService"
    i18nFileName="mymoduleauth"
    revisionNumber="1"
    i18nKey="iplanet-am-auth-mymoduleauth-service-description">
    <Organization>
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-server"
    type="single"
    syntax="string"
    i18nKey="a102">
    <DefaultValues>
    <Value>msg1dev.ec-lille.fr:1389</Value>
    </DefaultValues>
    </AttributeSchema>
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-base-dn"
    type="single"
    syntax="dn"
    i18nKey="a103">
    <DefaultValues>
    <Value>dc=ec-lille,dc=fr</Value>
    </DefaultValues>
    </AttributeSchema>
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-search-base-dn"
    type="single"
    syntax="dn"
    i18nKey="a104">
    <DefaultValues>
    <Value>ou=people,dc=ec-lille,dc=fr</Value>
    </DefaultValues>
    </AttributeSchema>
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-bind-dn"
    type="single"
    syntax="dn"
    i18nKey="a105">
    <DefaultValues>
    <Value>cn=Directory Manager</Value>
    </DefaultValues>
    </AttributeSchema>
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-bind-passwd"
    type="single"
    syntax="password"
    i18nKey="a106">
    </AttributeSchema>
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-auth-level"
    type="single"
    syntax="number"
    i18nKey="a500">
    <DefaultValues>
    <Value>0</Value>
    </DefaultValues>
    </AttributeSchema>
    </Organization>
    </Schema>
    <Configuration>
    <OrganizationConfiguration name="/">
    <AttributeValuePair>
    <Attribute name=
    "iplanet-am-auth-mymoduleauth-primary-bind-passwd"/>
    <Value>adminadmin</Value>
    </AttributeValuePair>
    </OrganizationConfiguration>
    </Configuration>
    </Service>
    </ServicesConfiguration>
  5. (OPTIONAL) Create a localization properties file for the new authentication module.
    A localization properties file specifies the screen text that an administrator will see when directed to an authentication module's service page in the OpenSSO console, as well as messages (error or otherwise) displayed by the module. Here are some concepts behind the creation of this file.

    • The data following the equal (=) sign in each key/value pair could be translated to a specific language as necessary.
    • The alphanumeric keys (a1, a2, etc.) map to fields defined by the i18nKey attribute in the corresponding amAuthmodulename.xml service file.
    • The alphanumeric keys also determine the order in which the fields are displayed in the OpenSSO console. The keys are taken in the order of their ASCII characters (a1 is followed by a10, followed by a2, followed by b1). For example, if an attribute needs to be displayed at the top of the service attribute page, the alphanumeric key should have a value of a1. The second attribute could then have a value of either a10, a2 or b1, and so forth. The files are located in OpenSSO-Deploy-base/WEB-INF/classes and follows the naming format amAuthmodulename.properties; for example, amAuthLDAP.properties.

    Use one of the provided authentication module localization properties files in the source code as a template for creating the file and copy it to the aforementioned directory when complete.
  6. Develop the custom authentication module.
    Custom authentication modules extend the com.sun.identity.authentication.spi.AMLoginModule class and must implement the init(), process() and getPrincipal() methods. The module should also invoke the setAuthLevel() method. Other methods that can be implemented include setLoginFailureURL() and setLoginSuccessURL() which define URLs to which the user is sent based on a failed or successful authentication, respectively. To make use of the account locking feature with custom authentication modules, the InvalidPasswordException exception should be thrown when the password is invalid.
  7. (OPTIONAL) Add post processing features.
    The com.sun.identity.authentication.spi.AMPostAuthProcessInterface interface can be implemented for post processing tasks on authentication success, failure and logout using the methods onLoginSuccess(), onLoginFailure(), and onLogout(), respectively. The Authentication Post Processing Classes are defined in the Core Authentication Service and configurable at several levels such as at the realm or role levels.
  8. Access http://osso-host.osso-domain:osso-port/opensso/ssoadm.jsp from a browser and choose create-svc to create the service in OpenSSO.
    Copy the authentication module's service file to the text box.
  9. Choose the register-auth-module option (also on ssoadm.jsp) to register the custom authentication module with the Core Authentication framework.
    Enter the complete module name including the prepended package.
  10. Restart OpenSSO.
    The custom authentication module is now listed under the Configuration tab as an Authentication option.

NOTE: After deploying opensso.war, you can also point a browser to http://osso-host.osso-domain:osso-port/opensso/ samples/authentication/AuthSampleLoginModule to access the sample, How to Write Sample LoginModule using AMLoginModule SPI (Service Provider Interface).

Now enjoy the More, More, More, the Andrea True Connection's #1 hit from 1976. That's when sex stars had class! (But where's the Connection?)

Monday Jan 12, 2009

Give Him OpenSSO Resource-based Authentication

Policy agents deployed to web containers and web proxy servers protect content from unauthorized intrusions. Access to this content (services, for example) are controlled through policies configured with OpenSSO. Here is a description of the interactions that occur when a policy agent interacts with OpenSSO.
  1. A policy agent intercepts the user's request and validates any authentication credentials contained within it. If the existing authentication level is insufficient, the OpenSSO Authentication Service will present a login page for an authentication upgrade. The login page prompts the user for the credentials appropriate to the configured module.
  2. The Authentication Service verifies that the user credentials are valid. For example, the LDAP authentication module verifies that the user name and password are the same as those stored in the LDAP identity data store. If other authentication modules are passed to the user (such as RADIUS or Certificate), the credentials are verified with the appropriately configured identity data store.
  3. Assuming the user's credentials are properly authenticated, the policy agent examines the policies assigned to the user.
  4. Based on the aggregate of the user's configured policies, the individual is either allowed or denied access to the resource.

NOTE: In this scenario, if the user attempts access to a web resource without authentication credentials, the agent redirects the user to the login page of the default authentication module. (Even if the resource is protected by a different authentication module, the user must first authenticate using the default authentication module.)

Because some customers require a scenario in which the user authenticates against a particular module based on the resource being accessed, the Gateway servlet provides resource-based authentication; there is no need for the user to authenticate to the default authentication module to access the protected web resource. When using the Gateway servlet:
  • A web resource can not be defined in more than one policy. For example, if abc.html is defined in a policy definition as requiring LDAP authentication, abc.html can not be defined in a second policy definition as requiring Certificate authentication.
  • You can use the level and scheme conditions only when defining policies that the servlet will examine.
Additionally, the Gateway servlet does not work across internet domains. Use the following list to configure your deployment to use the Gateway Servlet.
  1. Configuring the Web Container
  2. Configuring OpenSSO
  3. Configuring the Policy Agent
  4. Testing the Servlet
Configuring the Web Container

Generically speaking, you must ensure the following configurations on your web container. Check your container's documentation for information on how to do them.
  1. Check that the following certificates are installed:

    • A certificate for the server (Server-Cert).
    • A certificate for the trusted Certificate Authority.
  2. Add a listen socket for simple Secure Sockets Layer (SSL) and one for SSL client authentication.
  3. Ensure that the listener port configuration requires SSL for client authentication.
Configuring OpenSSO

  1. Log in to the OpenSSO console as the administrator.
  2. Click the Configuration tab and the Authentication tab under it.
  3. Click the Certificate Service Name link.
  4. Enable Match Certificate in LDAP by checking the box.
  5. Select Subject UID as the value for Certificate Field Used to Access User Profile.
  6. Enter 54430 as a value for SSL Port Number.
    This port number must match the port number used for the web container's SSL client authentication listener port in the previous procedure.
  7. Type 2 as the value for the Authentication Level attribute.
    The value used must be greater that the level defined for LDAP authentication.
  8. Click Save.
  9. Click Back to Service Configuration.
  10. Under the appropriate realm, add policies for three URL resources:

    1. policy1 has a condition of LDAP authentication only for http://agent-machine.domain/banner.html.
    2. policy2 has a condition of Cert authentication only for http://agent-machine.domain/banner2.html.
    3. policy3 has a condition of LDAP authentication and a level of Certificate authentication for http://agent-machine.domain/banner3.html.
See the OpenSSO Enterprise 8.0 Administration Guide for the official documentation on configuring OpenSSO Enterprise 8.0 for resource-based authentication.

Configuring the Policy Agent

  1. Go to the installation directory for the agent protecting the resource on the web container host machine. For example, on Application Server, change to AppSvr-Directory/agents/j2ee_agents/appserver_v9_agent/Agent_001/config/.
  2. Change the value for com.sun.am.policy.am.loginURL from http://machine-name.domain:port/opensso/UI/Login to http://machine-name.domain:port/opensso/gateway in OpenSSOAgentBootstrap.properties. It is the only change to the policy agent configuration.
Testing the Servlet

After these configurations, the test results are:

  • Access to resource A is permitted only after successful LDAP authentication.
  • Access to resource B is permitted only after successful Certificate-based authentication.
  • Access to resource C is permitted only after both successful LDAP and Certificate-based authentication.

Now that you've configured and tested resource-based authentication, the Shangri-Las are gonna give you a great big kiss with Give Him a Great Big Kiss. I was reminded of this song when it was used in a movie I saw this weekend called Stonewall, an account of the Stonewall riots of 1969. Worth checking out!

Wednesday Dec 03, 2008

A Spring Framework in the OpenSSO Step

OpenSSO Community member Miquel has developed an extension based on Spring Security. Spring Security provides comprehensive security services for J2EE-based software applications with an emphasis on those built using the Spring Framework, an open source Java application framework.

In honor of our new extension, enjoy The Go-Betweens Spring Rain.

Thursday Jul 31, 2008

Create an OpenSSO Custom Authentication Module

In case you haven't seen it yet, wikis.sun.com has an entry here that contains the procedure for creating a custom authentication module for OpenSSO - ok, Access Manager but you know the history. Note that there is an error pointed out at the bottom of the entry itself so take a look at that first.

And when you are done authenticating, you can be sure that the identity is, indeed, the son of a preacher man. Ahhhh, Dusty.

08/09/08 UPDATE: Oy gevalt to that segue.

Wednesday Jun 06, 2007

Authentication Login URLs and Redirection URL Precedence

Just added the Subject article, Authentication Login URLs and Redirection URL Precedence, to the OpenSSO Topics and Tasks page. The official Access Manager Administration Guide list a whole bunch of attributes for Redirection URL Precedence but it uses the back-end attribute names defined in the source as opposed to the attribute names the administrator will see on the console. Check it out!

Also added a link to this article I found on Sun Developer Network called Securing Site Access With CardSpace and OpenSSO: An Overview. It describes the benefits, architecture, and process of an authentication module using the open source project CardSpace with OpenSSO.
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