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

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

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

I miss The Housemartins.

Validsoft's VALid provides out-of-band multi-factor Authentication. I allows for instance to validate a user's identity to ring back the individual on a registered phone number or send SMS in order to obtain a PIN code which needs to be entered in the login screen.
I made a first cut of a VALid authentication module available as an OpenSSO extension. It allows 2nd-factor authentication through mobile callback and SMS. It doesn't however cater for the display of progress messages in the login process and the flexibility to let the user pick the callback type.
In order to compile and run it you need to get the VALid client libraries from ValidSoft (enquiries@validsoft.com) - of which you probably got the VALid server in the first place.

Here's the source code:
https://opensso.dev.java.net/source/browse/opensso/extensions/authnvalid/
Here's handy way to create a SAML assertion programmatically using OpenSAML (www.opensaml.org).

Dependencies:
xalan.jar (2.7.1), xercesImpl.jar, xml-apis.jar,
opensaml-1.1.jar, xmlsec-20050514.jar,
log4j-1.2.5.jar, commons-logging-1.03.jar, commons-codec-1.3.jar
Here's the Java Source:
import org.opensaml.SAMLAssertion;
import org.opensaml.SAMLException;
import org.opensaml.*;

import java.util.Date;
import java.util.HashSet;

public class AMUserAssertion {

   private static String strIssuer = "Example:FrontEnd";
   private static String strNameID = "testUserID";
   private static String strNameQualifier = "Example:FrontEnd";
   // private static String strNamespace = "urn:oasis:names:tc:SAML:1.0:assertion";
   private static String strNamespace = "urn:bea:security:saml:groups";
   private static String strAttrName = "Groups";
   private static String strAuthMethod = "SunAccessManager";

   public static void main(String args[]) {
      try {
          // Crate the assertion
         SAMLAssertion assertion = new SAMLAssertion(strIssuer, null, null, null, null, null);
         // Create the subject
         SAMLSubject subject = new SAMLSubject(new SAMLNameIdentifier(strNameID, strNameQualifier, SAMLNameIdentifier.FORMAT_UNSPECIFIED), null, null, null);

         subject.addConfirmationMethod(SAMLSubject.CONF_SENDER_VOUCHES);

         // Create the authentication statement
         Date date = new Date();
         SAMLAuthenticationStatement authStatement = new SAMLAuthenticationStatement(subject, strAuthMethod, date, null, null, null);

         assertion.addStatement(authStatement);

         // Create the attribute statement
         SAMLAttribute attrGroups = new SAMLAttribute(strAttrName, strNamespace, null, 0, null);
         // Here some hardcoded values for the groups attributes
         attrGroups.addValue("AssetManager");
         attrGroups.addValue("Employee");

         HashSet set = new HashSet();
         set.add(attrGroups);

         SAMLSubject subject2 = (SAMLSubject) subject.clone();
         SAMLAttributeStatement attrStatement = new SAMLAttributeStatement(subject2, set);

         assertion.addStatement(attrStatement);

         SAMLDoNotCacheCondition condition = new SAMLDoNotCacheCondition();
         assertion.addCondition(condition);

         System.out.println("AMUserAssertion 1:\n"+assertion.toString());
      }
      catch (Exception e) {
         e.printStackTrace();
      }
   }
}
The output looks like:
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" AssertionID="_4e138dee03e2e826b58b9310e2d8a1e5" IssueInstant="2009-07-01T10:03:06.103Z" Issuer="PND:FrontEnd" MajorVersion="1" MinorVersion="1">
   <Conditions>
      <DoNotCacheCondition></DoNotCacheCondition>
   </Conditions>
   <AuthenticationStatement AuthenticationInstant="2009-07-01T10:03:07.078Z" AuthenticationMethod="SunAccessManager">
      <Subject>
         <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="PND:FrontEnd">testUserID</NameIdentifier>
         <SubjectConfirmation>
            <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod>
         </SubjectConfirmation>
      </Subject>
   </AuthenticationStatement>
   <AttributeStatement>
      <Subject>
         <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="PND:FrontEnd">testUserID</NameIdentifier>
         <SubjectConfirmation>
            <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod>
         </SubjectConfirmation>
      </Subject>
      <Attribute AttributeName="Groups" AttributeNamespace="urn:bea:security:saml:groups">
         <AttributeValue>AssetManager</AttributeValue>
         <AttributeValue>Employee</AttributeValue>
      </Attribute>
   </AttributeStatement>
</Assertion>"


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.

This sample demonstrates RESTful web services using JSR311 API and OAuthToken.


You can use ssoadm CLI to automate the OpenSSO service configuration.  In the next few blog entries I am planning to give some examples on how to perform certain configuration changes using the ssoadm CLI. In this article I am going to show you how to create an Authentication Chain. You should have configured the CLI  as a prerequisite.



Here is the scenario:



  • Create an LDAP auth module with Name "MyLDAP" pointing to the ldapserver myldap.example.com:5389  with BIND DN "cn=myldap manager"

  • Create an Authentication Chain 'myauthcfg' with MyLDAP as the required module


Creating LDAP Authentication Module



  • ./ssoadm create-auth-instance -m MyLDAP -t LDAP -u amadmin -f /tmp/.pass -e /


 Update the LDAP Server Properties


Add the ldap server configuration details to the newly created auth module 'MyLDAP'




  • ./ssoadm update-auth-instance -e / -m MyLDAP -u amadmin -f /tmp/.pass -a "iplanet-am-auth-ldap-server=myldap.example.com:5389" "iplanet-am-auth-ldap-bind-dn=cn=myldap manager"



Create the Authentication Chain


When you create the auth chain there will be no modules added to it, you need add it later


Create the Auth Chain named 'myauthcfg'





  • ./ssoadm create-auth-cfg -e / -m myauthcfg -u amadmin -f /tmp/.pass


Add Auth Instances to  Auth chain 


Add the MyLDAP as the required module to the auth chain 'myauthcfg'





  • ./ssoadm update-auth-cfg-entr -m myauthcfg -e / -u amadmin -f /tmp/.pass
    -a "MyLDAP|REQUIRED"


Listing Auth Chains



You can list the available authentication configurations in a realm using the list-auth-cfgs  sub command.


./ssoadm list-auth-cfgs -e / -u amadmin -f /tmp/.pass


Authentication Configurations:

ldapService

myauthcfg

Listing Authentication Instances


You can also list the available authentication instances in a realm using the list-auth-instances sub command



  • ./ssoadm list-auth-instances -e / -u amadmin -f /tmp/.pass




Authentication Instances:
WSSAuthModule, [type=WSSAuthModule]
MyLDAP, [type=LDAP]
Federation, [type=Federation]
LDAP, [type=LDAP]
HOTP, [type=HOTP]
DataStore, [type=DataStore]
SAE, [type=SAE]






As I blogged the other day, I'm in Brazil this week, speaking at the Javali and FISL conferences in Porto Alegre. I'm all done with my sessions now, and, as promised, here are the slides:

The Javali presentation is a fairly deep dive into OpenSSO's brand new OAuth implementation, while the FISL slides are a higher level overview of identity services in OpenSSO. Grab one or both and mix yourself a caipirinha for the full Brazilian experience

こんにちは。 先日のエントリ で紹介しましたが、明日 のようにSun主催のクラウドセミナーが開かれます。
残念ながら私は現地に行くことはできないのですが、Sunのミドルウェアチームからは、寺田さんが講演で話をして、他のメンバーがデモの展示も行ないます。
展示するデモは、GoogleAppsとAmazon EC2 上のOpenSSOのSAML連携のデモです。 で紹介しているように、外部のSaaSを利用した際に社内のウェブアプリと連携することは利便性、セキュリティ、業務効率性といった観点から非常に大事です。OpenSSOを使えば、社内ウェブアプリとGoogleAppsのようなSaaSアプリとのシングルサインオンが可能になります。

GoogleAppsとのシングルサインオンはSAMLをサポートしている時点で技術的には可能です。
去年の12月に開催されたSunTechDays でもデモをしています。 今回は去年おこなったデモに、
  • クラウドセミナーなんだから、サーバ自体もクラウドに乗せちゃおうっということでOpenSSO 自体もクラウド上に構築しています。 Amazon EC2上に乗せています。(構築と言っても、30分くらいしかかかってないですけどね。)
  • OpenSSO Express Build7 を使うことで、GoogleAppsとの連携設定が劇的に簡単になっています。
の2つの新しい内容が加わったものになります。ぜひ足をお運びください。

_kimimasa
ALT DESCR

The 10th FISL starts this week. Like previous years, it looks like a lot of fun: the Program is full of good content, and there is also Porto Alegre... FISL starts on the 24th and it is preceded by Javali, an event focused on Java, on the 23rd (Agenda).

I did a quick pass through the FISL program to highlight some sessions, including those related to GlassFish Projects and friends:

• Arun on GF, MySQL and NetBeans (S205) (Arun's note)
• Mauricio on OSGi in GFv3 (S736)
• Ludo will talk about OpenDS (S473) (Ludo's note)
• Fabiane on Hudson (S733)
• Pat on OpenSSO (S360) (Pat's note)
• Fabio Veloso on Jersey (S282)

Other talks related to GlassFish include

• On OpenJDK, Bruno (S734) and Charlie (S226)
• On OpenSolaris Rafael (S600) and Brian (S749)
• On NetBeans et al, Geertjan (S735), and
• On OSS, Simon (S757),

I wish I was there! If you attend FISL or Javali, please report back.

I just got confirmation that I'm on the bill at the Javali event next Tuesday, June 23, in Porto Alegre, Brazil. Javali, organized by SouJava and RSJUG, focuses on Java and free software, and is held immediately prior to FISL (on which more below). I'll be doing quite a deep dive on the secure RESTful web services (via OAuth) work we have going on right now, which was first seen in public a few weeks ago at CommunityOne West and JavaOne. Javali will be at the Porto Alegre Serpro offices, Av. Augusto de Carvalho, 1133, from 09:00 to 20:00. I'm on at 18:30 in the Bill Joy Room, just before the pizza, assuming I make my 1 hour layover in Buenos Aires!

As I mentioned above, Javali precedes FISL, now in its 10th year, South America's biggest open source conference with, according to the FISL home page, over 6000 attendees registered. I spoke at FISL 9.0 last April, and, I have to say, had a GREAT time. I saw an incredible display of energy and enthusiasm for all things open source, from kernel hacking to Ruby on Rails via every application of Java, although I think our evening expeditions in search of churrasco and caipirinhas probably also contributed to my positive recollections

My session this year, 'Open Source Identity Services with OpenSSO', on Friday June 26 at 09:00 in room 40T, looks at the three different approaches we take to identity services in OpenSSO - insulating applications from identity via container plugins, support for standards such as SAML, and lightweight SOAP and REST for interacting directly with OpenSSO. I'll be covering the secure RESTful web services demo again, but it will be a much higher level view than the Javali presentation.

So - probably not enough notice for anyone to book a trip to Brazil, but, if you're going to be there anyway, drop in one one or both sessions and say "Hi"! And bring the cachaça!

UPDATE - slides posted.

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

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

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

Move over, Madonna. THIS was the first time I had seen anyone use the telephone operator microphone in a live performance.
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!

1.0 Install and Configure Oracle Internet Directory OID


There are lot of resources available on the internet  to install and configure the OID, I would suggest this article for the beginners on OID, found it very useful. For simplicity I have assumed OID is installed and configured with default settings with a root suffix dc=opensso,dc=java,dc=net. If your suffix is different from this you should change the suffix values appropriately in the respective files.


2.0 Preparing OID to be used as OpenSSO user store


This  section includes two parts one describing on how to extend the OID schema to accommodate OpenSSO specific user  attributes the other details about the special users and privileges required to manage the user store from OpenSSO perspective.


2.1 Extending the OID Schema


This is the critical part of the process with out this schema some of the user management features of OpenSSO cannot be achieved like the OpenSSO provided password reset feature or the user account lockout.



To extend the schema just download the schema file from here.


ldapmodify    -h OID_HOST -p PORT -D "cn=orcladmin" -w PASSWD -f am_remote_oid_schema.ldif


2.2 Adding the privilege and the custom user entries


 Since the OID schema is extended to include the OpenSSO attribute certain attributes of OpenSSO are critical from security point of view, normal users should not be able modify those attribute such as inetuserstatus, to prevent this self modification an ACI needs to be included in the OID configuration.



OID can be used as a profile,authentication and policy store, for
authentication and policy subjects read only permissions are enough.
For profile read and write permissions are required. 



There will be a user created under the root suffix



  • cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net - this user has realm admin permissions under the suffix



  • dn: ou=opensso adminusers,dc=opensso,dc=java,dc=net
    changetype:add
    objectClass: top
    objectClass: organizationalUnit

    dn: cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net
    changetype:add
    objectclass: inetuser
    objectclass: organizationalperson
    objectclass: person
    objectclass: top
    cn: openssouser
    sn: openssouser
    userPassword: amsecret12

    dn: cn=RealmAdministrators, cn=Groups, cn=OracleContext,dc=opensso,dc=java,dc=net
    changetype:modify
    add:uniquemember
    uniquemember:cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net




    In addition to the above you need to add appropriate ACI to prevent the self modification of certain security user attributes. This is not part of this procedure because adding this requires quite a bit of testing which I could not do it.



    orclaci: access to attr=(objectclass,inetuserstatus,iplanet-am-user-login-status,iplanet-am-user-
    account-life,iplanet-am-session-quota-limit,iplanet-am-user-alias-list, iplanet-am-session-max-se
    ssion-time,iplanet-am-session-max-idle-time,iplanet-am-session-get-valid-sessions,iplanet-am-sess
    ion-destroy-sessions,iplanet-am-session-add-session-listener-on-all-sessions,iplanet-am-user-admi
    n-start-dn,iplanet-am-auth-post-login-process-class,iplanet-am-saml-user,iplanet-am-saml-password
    ,iplanet-am-user-federation-info,iplanet-am-user-federation-info-key,sun-fm-saml2-nameid-info,sun
    -fm-saml2-nameid-infokey,sunAMAuthInvalidAttemptsData,memberof,member) by self (noselfwrite)


    You should be able to download the above LDIF from here



     Run the following command to load the LDIF



    ldapmodify    -h OID_HOST -p PORT -D "cn=orcladmin" -w PASSWD -f  add_opensso_config_oid.ldif



    Now your Oracle Internet Directory is ready to be used as a userstore for OpenSSO.


    3.0 Create  User data store in OpenSSO



    Once the steps 1 through 2 are accomplished successfully  you can go ahead
    and create a new LDAPv3 type datastore pointing to the OID you have
    just configured.  I am going to show you the less error prone method to
    create the user store that point to OID. I am assuming the ssoadm
    command line tool is already confgured with your OpenSSO server.



    You just need to run  the following command



    • ssoadm create-datastore -m "OID User Store" -t "LDAPv3" -D datastore_oid_attrs.txt  -u amadmin -f /tmp/.pass_of_amadmin  -e  /



    make sure you have replaced the  OID server's name and port  in the
    datastore_oid_attrs.txt. Now you can start creating and managing
    users that are stored in the OID server. 




    If you want to use this server as LDAP authentication source, you
    configure the LDAP auth instance with the bind user cn=ldapuser, like
    wise for the policy configuration service.


    4.0 Removing the OpenSSO schema from OID


    At some point if you want to remove the schema and the adminstrative entries along with the privileges added by the section 2.2, you can simply run the following command


  • ldapmodify -h OID_HOST -p PORT -D"cn=orcladmin" -w secret12 -c  -f remove_am_remote_oid_schema.ldif

    This will remove the OpenSSO  user schema.



  • ldapmodify -h OID_HOST -p PORT -D"cn=orcladmin" -w secret12 -c  -f remove_opensso_config_oid.ldif

    This will remove the ACIs and the administrative users like cn=openssouser from the Oracle Internet Directory. 


    5.0 Limitations



    • Persistent search control is not supported by OID so the change notification will not be happening at the OpenSSO side, you need to wait for the cache time out. 


    • Password polcies, extensive group management yet to be validated, however the static groups seems to be working fine in my testing



  • If you're in the Chicago area next week you might be interested in attending the Chicago Java Users Group (CJUG) meeting on Tuesday (June 16 2009) - Kiran Ramineni, Principal at Ramp Info, will be presenting on OpenSSO and Identity Federation. The event starts at 6pm in the Lewis Towers Ballroom, Beane Hall at Loyola University of Chicago, and is free to CJUG members and first time guests. Sounds like a bargain to me, so get yourself down there next Tuesday night and then leave a comment here to let us know how it went!

    こんにちは。
    ちまたでは、Google Apps Sync for Microsoft Outlook の話題で持ちきりですね。(もちきりではないかな。。。)Exchange からGmailに移行した場合でも、Outlookを使い続けるためのツールですね。これはなかなか便利でしょうし、Exchangeへの対抗策として有効でしょう。

    さて、メールはExchangeからGmailへ移行したとしましょう。カレンダや、アドレス帳、タスク管理もGoogel Apps に移行したとしましょう。

    でも、社内Webアプリは移行できますか。できませんよね。。でも、社内のWebアプリとGoogle Apps 連携したいですよね。シングルサインオンしたいですよね。

    そんなときはSAMLです。Google Apps もSAML対応しています。 Google Apps のビッグユーザとして有名な日本大学のケースでも、SAML対応がキーポイントになったようです。以下引用。
    日本大学は、Google Apps Education Edition の導入を決定してから稼動まで約 2.5 ヶ月で実現した。要求仕様として個人情報保護の観点から必要以上の情報を Google 社に提供しないという機密性、そしてアカウント情報を学内各種情報システムと連携という利便性、機密性と利便性というありがちではあるものの相反する要求を実現する必要があったが Google 社が提供する Provisioning API と SAML ベースの Single Sign-On (SSO) API の利用によって実現への確証を得た。Provisioning API を用いると Google Apps のシンプルな管理機能を大学組織に合致した運用形態に作り替えることができる。SSO を用いればキャンパス内の全ての IT サービスへの展開をも可能とする。いっけん Google 社の既製品をそのまま使っただけのように思われがちだが Web 2.0 時代のオープンな API を用いることで日大色の Google Apps Education Edition に仕立てた。
    Google Apps Education Edition の導入事例: 日本大学
    では、SAMLを使って、Google Apps とシングルサインオン連携をしたい場合には、どうすればいいのでしょうか。そんなときの強い味方がOpenSSOです。 SAMLにはもちろん対応していますし、Google Apps との連携設定が簡単に可能なウィザードも提供されています。

    Among the OpenSSO-related news items that popped up while I had my head down over the past few weeks, I noticed the Google Blog entry and Valeo press release concerning the global industrial group's Google Apps deployment - 30,000 Valeo employees now have access to a new communication and collaborative working platform based on Google Apps Premier Edition and supported by Capgemini, one of the largest enterprise deployments of Google Apps to date.

    It's not mentioned in either story, but, if you a regular reader of Superpatterns, you'll already know that Capgemini deployed OpenSSO at Valeo to handle single sign-on, allowing Valeo employees to access their email at Google via their Valeo credentials, without having to manage a separate Google username/password.

    If you're looking at Google Apps, click here to download the 'starter kit' we recently produced, which explains exactly how to set up single sign-on to Google Apps using OpenSSO.

    Wow - is it really over a month since my last blog entry? I guess that's what happens when you get your head down into a project - in this case, building a demo for CommunityOne West and JavaOne 2009 to show off the latest OpenSSO features.

    The demo brought together a number of existing Java technologies - the Java Persistence API (JPA), the Jersey implementation of JAX-RS (aka JSR 311) on both the client and server, and JavaFX - with some new aspects of OpenSSO - fine-grained authorization (aka entitlements), OAuth protocol support, and a JDBC data store. Briefly, the demo centered on a cellphone account management system delivered as a JavaFX rich Internet application (RIA) client and a (more or less) RESTful web service back-end, communication between them secured by OAuth.

    I'll be uploading source code for the demo client and server apps to the OpenSSO project in the next few days, as well as documenting how to bring up the demo environment. Watch this space for updates!

    How To Determine whether the given LDAP server support persistent search


    the persistent search draft version control 2.16.840.1.113730.3.4.3 is implemented by many of the LDAP servers including


    • IBM(Tivoli Directory)

    • Novell(eDirectory)

    • Sun(DSEE)

    • OpenDS(OpenDS Directory Server 1.0.0-build007)

    • Fedora-Directory/1.0.4 B2006.312.1539

    perform the following search for the persistent search control 2.16.840.1.113730.3.4.3
    ldapsearch -p 389 -h ds_host -s base -b '' "objectclass=*" supportedControl | grep 2.16.840.1.113730.3.4.3


    Active Directory


    AD implements in a different form using the LDAP control 1.2.840.113556.1.4.528


    ldapsearch  -h AD_HOST -p PORT  -D"CN=Administrator,CN=Users,dc=test,dc=com" -w secret12 -s base  -b '' "objectclass=*" supportedControl | grep 1.2.840.113556.1.4.528



    こんにちは。
    相互運用性は、ビジネスにおいてITシステムをよりよく効率的に使っていく上で非常に大切です。
    Sunにとってはマイクロソフト環境との相互運用性は大きな課題であり、かつお客様からの強い要望でもあります。
    今回、Sunとマイクロソフトさんが共同で、OpenSSOとGenevaサーバとの相互連携に関するホワイトペーパーを作成しました。 先日発表された、Geneveサーバ(Beta2)とOpenSSOとのSAML連携に関するホワイトペーパーです。
    1. .Netでアプリケーションを開発しているけど、他の言語で作られたアプリともシングルサインオンしたい。
    2. SharePointを社内で使っているけど、外部のプロバイダや提携会社とID連携したい。
    といったお客様はご一読の価値ありです。

    _kimimasa 参考:マイクロソフトとSun関連エントリ
    こんにちは。

    少し前までは、ポータルサーバとかCMS(コンテンツマネジメントシステム)と言うと非常に高価なソリューションでした。また、高価なポータルやCMS(コンテンツマネジメントシステム)を購入しても期待したほどの効果がでなかったり、構築コストがかさんでしまうといった話もありました。
    もちろん価格の分だけかゆいところに手が届いたり、機能が豊富だったりする部分もありますが、「高嶺の花」っというところもあったと思います。特に中小企業さんだと手がでない価格帯のものもありました。
    そんなときに、登場するのはやっぱりオープンソースですね。

    っと前置きが長かったですが、セミナーのご紹介。 6月17日(水)の2時半開場です。是非是非おこしください。

    ちなみに、Liferayは、OpenSSOとの連携も可能です。 OpenSSOの情報を紹介している(OpenSSO - kimimasa - wikis.sun.com)でも と紹介しているので、チェックしてみてください。

    _kimimasa

    There was a question posted to our internal (Sun) alias, and I think I should share it out for the benefit of OpenSSO community. The question was “How to update OpenSSO configuration store password?”

    There are two types of datastore in OpenSSO server, namely the configuration datastore and user datastore. As the name suggest, the former stores the configuration data that are required by OpenSSO server to operate properly. The latter stores users related information, such as role, group and user entries.

    It can be done through Command Line Interface or Administration Console.

    The Command Line Interface way.

    1. Output the current server configuration XML
      ./ssoadm get-svrcfg-xml -u amadmin -f /tmp/fampass -s \
      http://owen1.red.iplanet.com:8080/opensso -o /tmp/serverconfig.xml

    2. Encrypt new password
      ./ampassword -e /tmp/newpassword

    3. edit /tmp/serverconfig.xml. replace admin password with the new encrypted password.
    4. Output the current server configuration XML
      ./ssoadm set-svrcfg-xml -u amadmin -f /tmp/fampass -s \
      http://owen1.red.iplanet.com:8080/opensso -X /tmp/serverconfig.xml

    The Administration Console Interface way.

    1. Login as amadmin
    2. select Configuration tab
    3. select Sites and Servers tab
    4. Choose the server
    5. select Directory Configuration tab
    6. set the password

    We have recently modified our Java build target to 1.5. Hence, you need Java Runtime version 1.5 and above to run OpenSSO Client. The Java runtime version requirement for OpenSSO server remains unchanged i.e. 1.5.

    This new client runtime requirement shall be in our next official release i.e. OpenSSO Express 8 which is scheduled to released in a couple of months from now.

    OpenSSO at JavaOne/CommunityOne... tons of interesting stuff!

    OpenSSO Community Day

    Join us Sunday May 31st, for OpenSSO Community Day at the Moscone Center in San Francisco. It's our 'unconference' before the main conference and discussions will include OpenDS and Identity Connectors. Just show up prepared to talk about any topic related to Sun's open source identity projects. As always attendance is free. Join our Meetup to participate in this discussion.

    CommunityOne West Conference

    Whether you're a developer, technologist, or student, join us Monday, June 1- Wednesday, June 3 at the Moscone Center for technical education, OpenSSO talks, and a Hands On Lab at CommunityOne West.


    Monday, June 1

    • Hands On Lab --Web Application Security with OpenSSO by Himanshu Vijay and Baby Sunil.
    • Pragmatic Identity 2.0--Invoking Identity Services with a Simplified REST/ROA Architecture by Daniel Raskin.
    • Metro Web Services, NetBeans IDE, GlassFish Application Server, and OpenSSO in Action with Amazon WS, Azure, and Office by Harold Carr.
    • Secure Web Services in Time for Tea, Using Metro and OpenSSO by Jonathan Scudder.

    Wednesday, June 3

    • Deep Dives-- Identity Management with OpenSSO: Deploy an Identity Management Solution in Four hours by David Goldsmith.

    JavaOne Conference

    Continue the fun with more OpenSSO related talks, a BOF, and a Hands On Lab at JavaOne Tuesday, June 2- Friday, June 5. Stop by our pod (#462) to talk with identity experts and get a free t-shirt and open source CD! And, don't miss the following identity-related presentations:

    Tuesday, June 2

    • Using and Participating in the OpenSSO Project by Sean Brydon, Pat Patterson, Aravindan Ranganathan.

    Wednesday, June 3

    • Designing and Building Security into REST Applications by Sean Brydon, Aravindan Ranganathan, Paul Bryan.

    Thursday, June 4

    • Pragmatic Identity 2.0: Simple, Open, Identity Services Using REST by Pat Patterson, Ron Ten-Hove.
    • Web Application Security with OpenSSO: From Simple Log-In to Single Sign-On to Federation by Pat Patterson, Himanshu Vijay, Baby Sunil.
    • A RESTful approach to identity-based web services by Hubert Le Van Gong, Marc Hadley.

    ALT DESCR

    A reminder that tomorrow, Sunday May 31st, is our GlassFish and OpenSSO Unconference and also the Party at The Thirsty Bear.

    The Thirsty Bear is a popular hangout during JavaOne; they have great food and drinks and it is very close to The Moscone (see Google, Live). An RSVP is appreciated to assess food needs.

    PS. I have not been able to post news recently because of J1/C1 preparations - plus this year's extra distraction - but this year my commitments are early in the week and I will try to catch up afterwards.


    OpenSSO team has a busy week ahead.

    1. OpenSSO Community Day 3.0 Sunday (1:00 PM until 7:00 PM) May 31st 2009, Moscone Center, SF, CA.

      Open discussions on all OpenSSO related features.

    2. CommunityOne West June 1-3 2009, Moscone Center, SF, CA.

      Hands On Lab. Web Application Security with OpenSSO.
      Monday June 1, 1:40 – 3:30 PM by Himanshu Vijay and Baby Sunil.

      Pragmatic Identity 2.0: Invoking Identity Services with a Simplified REST/ROA Architecture.
      Monday June 1, 11:50 AM – 12:40 PM by Daniel Raskin,

      Deep Dives. Identity Management with OpenSSO: Deploy an Identity Management Solution in 4 hours Learn how to build an identity management solution based on OpenSolaris, Open DS, and Sun OpenSSO Express 7.
      Wednesday, June 3, Morning Session. by Mrudul Uchil and David Goldsmith.

    3. JavaOne Conference June 2-5, 2009, Moscone Center, SF, CA.

      BOF-5275 – Using and Participating in the OpenSSO Project
      Tuesday night, June 02, 9:30 PM – 10:20 PM hosted by Sean Brydon, Pat Patterson and Aravindan Ranganathan.

      TS-5295 Designing and Building Security into REST Applications
      Wednesday, June 03, 2:50 PM – 3:50 PM by Sean Brydon, Aravindan Ranganathan, Paul Bryan.

      TS-4012 – Pragmatic Identity 2.0: Simple, Open, Identity Services Using REST
      Thursday, June 04, 10:50 AM – 11:50 AM by – Pat Patterson and Ron Ten-Hove.

      LAB-6727 – Web Application Security with OpenSSO: From Simple Log-In to Single Sign-On to Federation
      Thursday, June 4, 1:30 – 3:00 pm by Pat Patterson, Himanshu Vijay and Baby Sunil.

      BOF-4903 – A RESTful approach to identity-based web services
      Thursday, June 04, 7:30 PM – 8:20 PM by Hubert Le Van Gong and Marc Hadley.

    Ian Glazer from the Burton Group wrote a nice blog on having a meaningful conversation around the definition of entitlement management. Ian was responding to a blog by Ian Yip and basically states we need more specificity around entitlements in the context of access controls. I agree with Ian's sentiment and thought I'd take some time to discuss how Sun thinks about entitlement management when it comes to access controls.

    First, as Ian points out in his blog we agree that entitlement management is to vague a term and cuts across many facets of identity management including roles, provisioning, access controls and reporting. When it comes to access controls we've decided to refer to it as "entitlement enforcement" so that it's clear that we are talking about the run-time enforcement of access entitlements.

    Second, when we refer to entitlement enforcement we believe that we are discussing the fine-grained access controls around resources. That is, rather than protecting "doorways" or coarse-grained access we provide authorization decisions around all the "objects" within an application or resource (often referred to as fine-grained authorization). For example, a common scenario we see is in the financial services area and the need to provide entitlement enforcement around specific fields within a banking portal. For instance, a banking portal may want to provide access controls that limit the amount of money that subjects such as individuals, roles or groups can transfer. I may have the ability to transfer $1 million dollars and Ian may have the ability to transfer $5. Note that the access controls I'm talking about are not only specific to urls, but also other resources such as fields, calendars, etc.

    Third, entitlement enforcement requires policy enforcement points that are easy to deploy and scalable. Sun is approaching this in two ways. 1) OpenSSO can be deployed as a policy enforcement point or 2) we will be offering a Fedlet policy enforcement point, a lightweight method for embedding policy enforcement points within applications. The key to this effort is making it lightweight and performant at the same time. Basic jist is if you have all the capabilities to implement entitlement enforcement but it isn't repeatable and scalable in terms of deployment then it won't be practical to implement and could hinder adoption.

    Four, Sun believes that all aspects of an entitlement enforcement solution imply scale. Your policy store needs to scale. The user interface needs to scale to allow people to manage lots o' policies and the entitlement enforcement solution needs to be performant to ensure it can handle lots and lots of authorization transactions.

    Five, auditability and simulation of policies is important as well. Entitlement enforcement needs to fit in to the development process so that administrators and developers can work together to define applications, develop policies and test policies throughout development, QA, staging and production. Providing tools to do this and ensuring that admins can export policies from the entitlement solution so that they can develop error free scripts as they move from environment to environment is critical.

    Six, identity services are key to entitlement enforcement. The fine-grained nature of entitlements means there is a much larger burden on developers to tie policy to a centralized system. There needs to be several options that developers can use to handle embedding entitlements in the application or container. This includes lightweight identity web services such as OAUTH/REST, standard protocols such as SAML/XACML and complete abstraction via agents. Depending on the customer, we believe you need to support multiple options. Whereas a Web 2.0 company may be very excited about REST a financial services company may be more focused on agents and completely abstracting authorization from the developer. As Gerry points out, there are many ways to do this whether it be using XACML, WS*, OAUTH, etc, etc, etc.

    Finally, Sun has a unique belief that entitlement enforcement should be part of your web access management solution. This is not specific to the definition of entitlement enforcement, but rather our belief around how to pragmatically implement it. Deploying separate WAM solution and entitlement enforcement solution adds unnecessary complexity to your identity infrastructure and vastly increases the TCO. It means that organizations have multiple products to maintain and upgrade. It also means that customers will likely have multiple policy stores within their organization. From our perspective, WAM solutions were built to handle entitlement enforcement and it is a natural extension of web access management that is more likely to lead to customer adoption rather then requiring someone to license and deploy a separate component in their environment.

    Our entitlement solution is currently under construction at OpenSSO.org. It will be 100% XACML based and is focused on delivering everything I've described above. You can currently view it via the OpenSSO source code, but we will be providing more details shortly for you to test it out. We will also be showing the new capabilities at OpenSSO Community Day 3.0 in San Francisco this weekend. Make sure to attend so you can see it and provide feedback.

    こんにちは。

    オープンソースベースのOpenSSO Enterprise 8.0 のアップデートリリースである、OpenSSO Enterprise 8.0 Update 1が、リリースされましたので、お知らせします。 よりダウンロード頂けます。 もあわせてご参照下さい。

    _kimimasa

    I wanted to pass along a quick note about an upcomming webinar on Directory Services which will be held Wednesday, May 20.  The webinar will cover how to reduce cost and improve the speed and performance of your enterprise using directory services.  The conversation will go over the following:

    • How to use save cost by consolidating identity sprawl in your enterprise
    • How to meet agressive time-lines on a merger and acquisition
    • How to federate faster with virtual directories

    If you are interested, please sign-up here.  Even if you are not able to attend, registering will give you access to the replay.

    Oh, and that is not Craig MacDonald in the picture in the top-right.  I got this from a very talented photographer in the Creative Commons here.

    If you attend and want to see what I look like, the picture to the left was captured at the European Identity Conference by the very serious people at the Daily Mail the bastion of great journalism in the UK.



    こんにちは。 を書いていて、「やべ、大事なこと書くの忘れてた。。。」っと思い出したので書きます。
    オープンソースのシングルサインオン製品として、赤丸急上昇(死語??)のOpenSSOですが、moriyaさんの超力作のデータシート(カタログ)ができました。 これ一部あれば、お客様への製品説明もばっちりです。また、必要となるサーバ構成やサポートされているアプリケーションも記載されているのでデータシートとしてもご利用頂けます。

    まだ、ダウンロードされていない方はすぐにダウンロードしましょう!!
    私は紙で常に持ち歩いていますー(笑)

    _kimimasa