Patrick Petit's Blog

Projet Magellan pour le High Performance Cloud Computing (HPCC)

2011-12-21T04:39:00.000-08:00

Donc voila, c'est parti pour le projet Magellan qui a été officiellement sélectionné par le gouvernement le 16 décembre dernier dans le cadre du programme Investissements d'Avenir, Appel à Projet #1 du FSN pour l'Informatique dans les nuages. Voir article Journal du Net sur les résultats de la selection. Mes débuts chez Bull en tant qu'architecte et chef de file ont été intenses pour mettre au point ce projet et promettent de l'être plus encore en 2012 avec son démarrage effectif. Les autres partenaires du consortium incluent les sociétés ATEME et HPC-Project, l'Institut Telecom / Telecom Sud-Paris, le CEA-List, Inria-Reso, l'EISTI, et OW2. L'objectif est de réaliser le prototype d'une plate-forme de calcul intensif en mode cloud sur une base hardware bullx Extreme Computing fournissant entre autres des fonctionnalités avancées de visualisation interactive à distance.

OpenAM Book Review

2011-03-27T05:16:00.000-07:00

The OpenAM book by Indira Thangasamy comes as a new entrant in a series of books that deal with open source single-sign-on and web access management. The OpenAM book covers well the fundamental concepts, properties and core capabilities of the product with the eyes of a well qualified practitioner. From that respect, this makes this book special and worth reading for anybody who intends to use OpenAM/OpenSSO in a production environment. You will learn in great details how to deploy, configure and manage the product in a highly available and secured environment by using the administration console and the sometimes cryptic, yet powerful, ssoadm command line interface. The book is easy to read and well organized. I don't think there are many other books on the market that go into as many real-world examples and nitty-gritty details about customizing the user experience through the console and schema of the configuration and identity stores. A dedicated chapter deals with how to federate identities with Google Apps and Salesforce.com services using SAML. This is of particular interest to those organizations which would like to externalize some of their business functions to the cloud without losing control over their IT service identities and access rights.

I wish the author could have covered more of the Federation services as well as some of the new capabilities that were introduced in version 9 including the Entitlement Service and the Web Services and Secure Token Service. That's definitely a prospect for a new edition to be written soon!

The First OpenAM Book

2011-01-28T06:20:00.000-08:00

I was kindly offered by Packt Publishing to receive a free copy of the first OpenAM book by Indira Thangasamy who's a former colleague at Sun Microsystems.
If you read my posts, you may have noticed that Identity and Access Management (IAM) and OpenSSO (the product name has changed from OpenSSO to OpenAM) account for some of my favorite topics. I am hoping the book tackles some of nitty-gritty details of the product's features, which can be tricky sometimes and not always well document. In short, I can't wait to review the book and share my impressions in these very columns.

Automated Delivery of an Identity-enabled Drupal in the AWS Cloud (Part 2)

2010-12-16T08:13:00.000-08:00

This the second part of a two-part post that examines how to automatically create an identity-enabled business application in the AWS cloud.

The first part discussed some rationals about the idea that open standards, free and open source software (FOSS), and automated configuration management bring business agility and better integration results than most one-size-fits-all identity integration solutions when it comes to extending the reach of an organization's authentication and access control policies outside of its administrative domain.

The second part intends to show how to effectively achieve this kind of integration with Drupal - the well-known open source content management system (CMS), and OpenAM - the market leading open source authentication, authorization, entitlement and federation product, and how the resulting identity integration can be automatically delivered into Amazon EC2 using the Opscode Chef tools and platform.

Let's try to do some work now...

Install and Configure Chef

Your best bet to get Chef running on your workstation is to follow the Opscode's How To Get Started Tutorial. You only need to complete Step1 and Step2. Creating a Chef client (Step3), at this point, is not necessary as we will do it "automagically" by using the knife bootstrap command.

After completing Step2 you should have a Chef repository that you will need to manage your cookbooks.

Import the required cookbooks
You need to download all the cookbooks that are in the dependency chain of the simplesamlphp cookbook, which I created for this post. The simplesamlphp cookbook has a direct dependency on the drupal cookbook, which in turn has a direct dependency over several other cookbooks including php, apache2 cookbooks. In other words, all the cookbooks required to build a full all-in-one LAMP stack.

You can download all these cookbooks separately from the Opscode's Cookbooks Repository or use knife. The best practice in working with the Opscode Platform is to always keep local copies of the cookbooks you are using in your chef-repo.

To import a cookbook with knife:
$ cd ~/chef-repo
$ knife cookbook site vendor cookbook-name

This command downloads cookbook-name, and creates a 'vendor branch' for you, which enables you to make your own custom changes to the cookbook and keep track of the differences between yours and the upstream. You'll find that there is no simplesamlphp cookbook in the Opscode's Coobooks Repository. That's normal because I didn't put it there since this cookbook is just a proof of concept for the post. You need to download it individually as well as a slightly modified version of the cookbook for drupal from GitHub.

Modify simplesamlphp cookbook
If you intend to run the same setup against your own instance of OpenAM server, you'll need to modify the simplesamlphp cookbook in oder to add the SAML v2 metadata descriptor of your own identity provider. For that you need to edit the file saml20-idp-remote.php under files and change the value of the idpname and idpid attributes within the drupalsaml role accordingly.

Upload all the cookbooks and roles
After you have modified your cookbooks or not, you need to upload them in your organization that resides in the Opscode Platform:

$ cd ~/chef-repo
$ knife cookbook upload --all
$ knife role from file roles/drupalsaml

Bootstrap the Drupal Server Instance in EC2

Chef's knife bootstrap command allows to literally bootstrap a fully functional Drupal server in EC2 out of a vanilla linux distribution. In this demo I use an EBS-backed Ubuntu 10.04 LTS (Lucid Lynx) Server 32-bit distribution with AMI id 'ami-f4340180'.
Don't forget to download the AWS key pair, for the AWS region you want to use, somewhere in your home directory (ex. ~/.ssh/eu-west-1-keypair.pem).

Launch a new EC2 instance from the AWS Management Console. Once the instance is running, copy it's Pulic DNS URL obtained from the dashboard and past it into the knife bootstrap command as shown below. Note the parameter -r 'role[drupalsaml]' that tells Chef to configure the instance as per the recipes and attributes defined in the drupalsaml role. The bootstrap is displayed to the instance's console starting with the installation of Chef itself, followed by the automated installation and configuration of all the required components (i.e. Apache2, PHP, OpenSSL, MySQL, Drupal, simpleSAMLphp, memcached, and sendmail).

# knife bootstrap ec2-46-51-163-241.eu-west-1.compute.amazonaws.com \
> -r 'role[drupalsaml]' -i ../.ssh/eu-west-keypair.pem -x ubuntu --sudoINFO: Bootstrapping Chef on 
0% [Working]3-241.eu-west-1.compute.amazonaws.com 
Get: 1 http://security.ubuntu.com lucid-security Release.gpg [198B]
Ign http://security.ubuntu.com/ubuntu/ lucid-security/main Translation-en_GB   
96% [Connecting to eu-west-1.ec2.archive.ubuntu.com (10.224.74.112)]
Ign http://security.ubuntu.com/ubuntu/ lucid-security/universe Translation-en_GB
Get: 2 http://security.ubuntu.com lucid-security Release [38.5kB]   
0% [Connecting to eu-west-1.ec2.archive.ubuntu.com (10.224.74.112)] [2 Release 
Hit http://eu-west-1.ec2.archive.ubuntu.com lucid Release.gpg                  

[.....]

ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed mixlib-authentication-1.1.4
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed mime-types-1.16
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed rest-client-1.6.1
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed bunny-0.6.0
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed abstract-1.0.0
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed erubis-2.6.6
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed moneta-0.6.0
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed highline-1.6.1
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed uuidtools-2.1.1
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com Successfully installed chef-0.9.12
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com 17 gems installed
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 12:55:20 +0000] INFO: Client key /etc/chef/client.pem is not present - registering
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 12:55:24 +0000] WARN: HTTP Request Returned 404 Not Found: Cannot load node ip-10-234-178-251.eu-west-1.compute.internal
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 12:55:27 +0000] INFO: Setting the run_list to ["role[drupalsaml]"] from JSON
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 12:55:29 +0000] INFO: Starting Chef Run (Version 0.9.12)

[.....]

ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 13:00:31 +0000] INFO: Navigate to 'http://ec2-46-51-163-241.eu-west-1.compute.amazonaws.com/install.php' to complete the drupal installation
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 13:00:43 +0000] INFO: Chef Run complete in 314.902713 seconds
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 13:00:43 +0000] INFO: cleaning the checksum cache
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 13:00:43 +0000] INFO: Running report handlers
ec2-46-51-163-241.eu-west-1.compute.amazonaws.com [Wed, 15 Dec 2010 13:00:43 +0000] INFO: Report handlers complete

A the end of the run, which in my case took about 5 minutes, you get a fully operational identity-enabled Drupal server instance federated with OpenAM. Note however, the message at the end of the configuration sequence:

Navigate to 'http://ec2-46-51-163-241.eu-west-1.compute.amazonaws.com/install.php' to complete the drupal installation.

This is because Drupal 6.x requires some manual configuration at the end of the installation. According to a conversation I had with Marius Ducea, who authored the cookbook for Drupal, that limitation should be removed with Drupal 7.

It is assumed that there is an OpenAM 9.5 server running somewhere in your data center or in the cloud. That OpenAM server must be accessible from the newly created Drupal instance. In this demo, I have created an OpenAM server in EC2 that is attached to an Elastic IP (static IP address). Chef is also used in the OpenAM server to help with automatically importing the metadata descriptor of the SAML2 service providers that are started in the same Opscode's managed organization. A unique recipe for OpenAM is executed on a regular basis, by chef-client running as a daemon, which only task is to search for any node that is assigned with the drupalsaml role, then retrieve the location of the service provider metadata reading the simplesamlphp.metadata attribute, to finally execute ssoadm import-entity locally. The openam recipe is fairly straighforward.

sps = []
url = String.new
hostname = String.new

search(:node, "role:drupalsaml") do |n|
  sps << n
end

sps.each do |n|
  url = n['simplesamlphp']['metadata']
  hostname = n['hostname']

  if !url.nil? && url.match(/^http/)
    bash "download-entity-descriptor" do
      user "root"
      cwd "/tmp"
      code <<-EOH
      wget #{url}
      EOH
      only_if "/usr/bin/test ! -f /var/log/entities#{hostname}"
    end

    execute "move_entity_descriptor" do
      user "root"
      command "mv /tmp/openam-idp /var/log/entities/#{hostname}"
      action :nothing
    end

    execute "ssoadm_import_entity" do
      user "root"
      command "/opt/openam/bin/ssoadm import-entity -u amadmin -f /opt/openam/password -m /tmp/openam-idp -t local"
      notifies :run, resources("execute[move_entity_descriptor]")
    end
  end
end

Now, you click on the screencast below to see how the identity federation between Drupal and OpenAM works in practice.

Automated Delivery of an Identity-enabled Drupal in the AWS Cloud (Part I)

2010-12-03T08:02:00.000-08:00

This post is composed of two parts that examine how to automatically create an identity-enabled business application to the AWS cloud.

The first part discusses the rationals behind the idea that open standards, free and open source software (FOSS), and automated configuration management bring business agility and better integration results than most one-size-fits-all identity integration solutions when it comes to extending the reach of an organization's authentication and access control policies outside its administrative domain.

To illustrate that claim, the second part will show how to effectively achieve an integration between Drupal-the well-known open source content management system (CMS), and OpenAM-the market leading open source authentication, authorization, entitlement and federation product, and how the resulting identity integration can be dynamically delivered in Amazon EC2 using the Opscode Chef tools and platform.

The problem in a nutshell

One of the main issues with creating new services in the AWS cloud, like any other public cloud, is that IT may loose control over who has access to what resources because the usual authentication and access control schemes that are commonly enforced within an organization's data center security perimeter may not be applicable in a multi-tenant environment. But IT surely needs to enforce authentication, sign-on (SSO), and access controls across the entire organization's IT services, so that, only those users that are properly authorized by IT are granted access, regardless of whether the application is running in-house or in the cloud. While centralized access control policies are relatively simple to support behind the enterprise's firewall, it is more difficult to support "in the wild" because IT has different types of control (or no control at all) over those software-as-a-service (SaaS) applications that are provided. As a result, compliance with regulations that mandate accountability for data security, privacy and auditing becomes challenging to achieve. Another challenge with moving an organization's business applications to a public cloud stands from the fact that IT doesn't want to duplicate identity and access management (IAM) information all over the place, as it may compromise security and the consistency of the organization's identity management system. In general, IT needs to leverage the identity information where they have it, meaning from within the organization's data center. Additional issues may arise from prohibiting the elasticity benefits of a cloud-operated infrastructure through locking users and applications in a more static compute environment that would prevent features like auto-scaling to work properly.

The devil is always in the details

Identity-enabling a business application, whether it is running on-premise or in a public cloud, almost always requires a fair amount of customization to address the nitty gritty details of an identity integration. I think this is because most business applications, regardless of how they are delivered, are almost never deployed out of the box, as is. If we take Drupal for example, the application does not work out-of-the-box in a SAML-based identity federation without requiring some significant customization. Note that I could also have taken the example of WordPress, Joomla, or MediaWiki. The same customization needs would apply.

Why is that? Simply because many of those applications pre-date the standardization and more pervasive use of federated identity technologies such as SAML. Those applications were designed with a built-in user management support in mind that is tightly coupled with the application's core functions. For example, Drupal creates, at install time, a SQL user database that is built out of a proprietary schema. Drupal needs that database to compute and render customized contents when a user logs in. This unfortunate fact of a fractured identity management landscape is responsible for the proliferation of the so called identity silos that are "traditionally" addressed by expensive identity management software, which mitigate the mess through the deployment of synchronization connectors. With that understanding in mind, it is easy to understand why data security and access control issues rank among the top cloud computing's adoption concerns in customer surveys.

No one-size-fits-all solution for the identity integration problem

Some newly entering cloud security vendors promote an architectural approach that can address the identity and access management divide by extending the reach of an organization's authentication and access control schemes to a cloud through the use of a general-purpose HTTP traffic interposition artifact known as HTTP Access Proxy Gateway. The role of an HTTP Access Proxy Gateway is to enforce user authentication and access control at the HTTP protocol level, somewhere in the cloud infrastructure, to protect access to resources. I would qualify this architectural approach as a one-size-fits-all solution, which in my opinion can hardy address the identity integration challenge, for business applications like Drupal, because it doesn't address the problem deeply enough to be truly usable. As we have seen above, the identity integration challenge needs to be addressed at the application level, as opposed to the network level, so that the core functions of the application can be maintained. Another issue with the proxy approach is that it creates a performance bottleneck (i.e. every HTTP request must be intercepted and checked against a valid session), and a single point of failure, which altogether doesn't play well with high availability and auto-scaling objectives.

A plug-in approach based on open standards and open source software

The starting point of the reflection builds upon the fact that Drupal, for example, can be easily extended. In open source software, modularity is more a rule than an exception. Therefore, thanks to its modular design, Drupal can incorporate plug-ins (called modules) that can modify the behavior of a particular core function. For example, in Drupal 6.x, a module that implements the hook_user API can alter the login / logout logic so that instead of getting a user's identity (i.e. email, first name, last name, ... attributes) from the database, the module can execute an authentication redirect to a trusted Identity Provider (idP) party, which in the end of the browser-based redirections choreography, returns a SAML assertion in the HTTP request. The assertion that is digitally signed is deciphered using the idP's public key to ensure that the user was properly authenticated against the organization's IAM authority. The SAML assertion contains the attributes of the user's identity that can be mapped to create (or update) a Drupal user account accordingly (if that account doesn't exist yet), and derive which role the user belongs to, and so, allows Drupal to enforce any role-based access control policy that may be defined.

All this is possible with using world-class FOSS from the simpleSAMLPHP project, led by UNINETT, and the OpenAM project, led by ForgeRock and the OpenSSO community.

The simpleSAMLphp project provides a native PHP application that supports the functions of a SAML V2 Service Provider (SP). In addition, simpleSAMLphp provides also a Drupal 6.x module that implements the hook_user API that can redirect authentication requests to a SAML V2 compliant idP like OpenAM. OpenAM is the IAM Swiss Army Knife solution in that it can perform authentication protocol conversions between SAML and many other enterprise's authentication standards including, but not limited to, LDAP, Kerberos, X509 certificate, and Radius.

Automated delivery of the identity-enabled application to Amazon EC2

In a series of foundational articles "Cloud computing and the big rethink", James Urquhart argues that with cloud computing, the very form of application delivery will change in that cloud-operated infrastructures and software development will play a major role. This comes from the need for more efficient application delivery and operations to address the accelerated need for new software functionality driven by end users. The most obvious place where this is happening is in the SaaS area. Cloud services that fall under this category are targeted at end users with specific business needs such as content management system (CMS) and customer relationship management (CRM). I think that this concept is particularly relevant to our identity integration case because it helps addressing the challenge of delivering compliant services in the cloud. As such, the creation of identity-enabled applications calls for a high level of automated operations so that the communicating parties can be properly and securely linked with no (or minimal) manual intervention.

This is were the Opscode Chef framework comes into place. Chef allows to bootstrap a virtual machine instance in an infrastructure supported by the Opscode Platform to dynamically install and configure all the software components that are required to run the identity-enabled application. The concept behind Opscode Chef is known as DevOps. This concept contrasts with the static image building process in that software installation and configuration is performed at runtime by program. A software configuration can be tweaked incrementally until a machine's state matches the desired end state without having to re-bundle a new image every time a tiny change is applied. Then, configuration management becomes more like a software development project, and so, breaking the divide between IT operations and software development.

With Opscode Chef, a configuration management task is called a recipe. It is written in a domain specific language (DSL) based on Ruby. Recipes can execute arbitrary Ruby code, but are mainly designed to execute actions on resources that are an abstract representation of system resources like packages, directories and files. For example to install Apache2 on Linux, one would just have to insert this block in a recipe, or event better, execute the default recipe of the Apache2 cookbook.

package "apache2" do
    case node[:platform]
    when "centos","redhat","fedora","suse"
      package_name "httpd"
    when "debian","ubuntu"
      package_name "apache2"
   end
   action :install
end

Once the Apache2 package is installed on the target machine, further invocations of that recipe would not attempt to reinstall the package. This behavior is referred to as being idempotent meaning unchanged when multiplied against itself (in mathematics). Opscode Chef also uses the concept of node, which can be associated with one or several roles, which themselves encapsulate runtime configuration parameters and a list of recipes to execute on the target machine. Recipes are packaged in a cookbook whose successive versions are typically managed in a source code control system such as Git or Subversion.

Voila, that is all for today. After this rather lengthly, and hopefully not too boring introduction, the second part of this post will discuss the concrete details of how to do the integration and run the automated delivery of the identity-enabled Drupal.

Information Card Authentication Module on OpenAM

2010-07-08T04:05:00.000-07:00

That was on my todo list for a while so this morning I took couple hours to verify that the OpenSSO Information-Card Module (a.k.a Authnicrp) works properly on the latest version of OpenAM 9.5. It appears that after modifying the Information-Card-enabled login page (i.e. infocard.jsp) to better reflect OpenAM's logotype graphics, everything worked out-of-the-box without a glitch meaning that OpenAM is 100% compatible with OpenSSO for that extension. The modification will be committed to OpenAM's subversion repository shortly. Below is a snapshot of what the login page looks like with that module.

Take-Away from Kuppinger Cole's Cloud Computing Security Foundations Virtual Conference (Part 2)

2010-03-30T09:48:00.000-07:00

Last week, on March 25-26, 2010 Kuppinger Cole sponsored a virtual conference on the topic of the Security Foundations for Cloud Computing. This Kuppinger Cole event has been organized around six identity and security-related questions that have been the subject of keynotes, panel discussions and analyst viewpoints. What follow are my "augmented| take-away notes of these viewpoints. In Part 1 of this post, I focus on the question of the "Cloud Computing security standards: which ones are already there and which ones are missing?". Part 2 of this post focuses on Martin Kuppinger's initial keynote around the question of "Cloud Computing, is it really a risk?"

Let's start by the end of the talk that concludes by debunking some of Cloud Computing security myths.

The Cloud is not inherently insecure. It mainly depends upon the provider's ability to do a proper job with the management of the security threats.
Conversely, the Cloud is not more secure than internal IT. Again, it depends on both the Cloud provider and internal IT expertise to deal with security threats.
A few Cloud security issues are new. Most already exit in internal IT and outsourced service providers.
Security is the problem of the Cloud provider only to the extent that it falls within the scope of its service delivery description. For example, an IaaS provider is not responsible for the security of the hosted operating system. A PaaS provider is not responsible for the security of the enterprise's data and applications. A SaaS provider is not responsible for the enforcement of the enterprise's governance and auditing policies.
We can store data outside of the EU zone, but careful considerations must be taken with regard to the EU's data security and privacy regulations enforced by the member states. For example, the EU privacy laws have established regulations that prevent the disclosure of sensitive personal information without explicit consent of the user to countries outside of the EU who do not honor equivalent privacy laws. To cope with this problem, some providers are now offering features to enable sticky location of data in security zones and regions across their distributed data centers
SAML unfortunately doesn't solve all the IAM issues in the Cloud. It helps to solve secure authentication issues, but doesn't help much with the larger problem of authorization.
It is somewhat true that security in the Cloud can't be measured. In particular, auditing and risk metric logs are missing, due in part to the lack of standardization, as described in Part 1 of this post, although the situation should improve over time.

CEOs and CIOs need to understand that Cloud Computing requires new policies and new controls because it may give rise to new IT risks that can have an operational and even strategic impact on the enterprise's efficiency and effectiveness. Adopting Cloud Computing to externalize computing resources poses the question of ascertaining opportunities versus operational and strategic risks.

When ascertaining Cloud security risks, we tend to think more of the technology side of the issue rather than of the information side. However, this way of thinking should be reversed because, in IT, the technology is here to manage the information. Not the other way around. Therefore, information should take precedence over technology when it comes to assessing the security and risks associated with Cloud Computing. For example, enterprises should start thinking about where the information is and what it means from a security and risk management perspective before moving to the Cloud. This eventually should help to decide what kind of information can reside in a public Cloud versus what kind of information should stay on-premises. Answering this question, along with what services or applications use this information, should also help to figure out which technology and Cloud provider can fulfill the enterprise's data security and risks management requirements. Another important consideration for CIOs at the beginning and along the course of the service procurement process is how well the service continuity and security requirements are met by the Cloud provider. The risk that the Cloud provider does not fulfill these requirements should be covered by the Service Level Agreement (SLA). Thus, a precise and standard description of the service level in the SLA should constitute the foundation of a risk mitigation strategy by looking at important service procurement characteristics such as information location, security of the transport, security of storage, authentication and authorization of users, auditing interfaces, and privileged user controls.

So, yes there are risks involved in using Cloud services. Some are new and some are old, although they can be exacerbated by the diversity and multiplicity of the actors. But most risks associated with Cloud Computing are well-known and not really new or specific to Cloud Computing. Knowing these risks and understanding how well they are covered (or not covered) through a detailed service description allows drawing risk mitigation plans. Depending on the quality and expertise of the Cloud provider, some internal security weaknesses can be reduced by externalizing the procurement of IT services. On the other hand, in doing so, new risks can arise. The crucial point of the decision-making process is to strike a fine balance between taking advantage of the Cloud's numerous benefits in terms of cost cutting and improved business agility, versus new risks arising from externalizing IT services.

Take-Away from Kuppinger Cole's Cloud Computing Security Foundations Virtual Conference (Part 1)

2010-03-29T10:15:00.000-07:00

Last week, on March 25-26, 2010 Kuppinger Cole sponsored a virtual conference on the topic of the Security Foundations for Cloud Computing. A much talked-about topic these days as the perceived lack of security in the Cloud is seen by some as a strong adoption inhibitor. For example, Gartner in "Top Five Cloud-Computing Adoption Inhibitors" claims that data security, and regulation non-compliance risks, rank amongst the top-five Cloud Computing inhibitors. Forrester in "How Secure is Your Cloud?" classifies CIOs' fears about Cloud Computing into three categories: Security and Privacy, Compliance and Other Legal and Contractual issues. We will see that to a certain extent these fears, uncertainties and doubts (FUD) around Cloud Computing have been overly emphasized. This Kuppinger Cole event has been organized around six identity and security-related questions that have been the subject of keynotes, panel discussions and analyst viewpoints. What follows are my take-away notes of these viewpoints. Part 1 of this post focuses on the question of the "Cloud Computing security standards. Which one are already there and which one are missing ?"[1], Part 2 will focus on Martin Kuppinger's initial keynote around the question of "Cloud Computing, is it really a risk?"

The good news is that the identity security standards we need for the Cloud are already there, and have been around for quite some time. The less good news is that Cloud Computing as a new industry is lagging behind in terms of these standards adoption and use compared to the traditional ITC industry. For example, access control standards are not being implemented by cloud providers as quickly and effectively as we would like. SaaS applications (e.g. Salesforce.com) as precursors of the Cloud Computing model are the driving forces toward SAML adoption. But in other segments, we see a gap in adoption that arises from the disconnection between XML-based standards and REST-based standards. There is a tendency for the enterprise world to focus on heavyweight, feature-rich, XML-based standards like SPML and SAML, whereas the Cloud world focuses more on lightweight REST-based standards and technologies such as OAuth and OpenID. This is viewed as a big disconnection between these two camps today. On the Web Services security front, WS-* protocols like WS-Trust are very much entrenched in the enterprise (e.g. Service Token Service (STS) in Geneva and OpenSSO/AM), whereas OAuth is more commonly used by SaaS providers. The Cloud Computing industry will have to decide which of these protocol families are going to be used; lightweight REST-based versus more advanced XML-based protocols. Enterprise security specialists are getting involved in this debate. The more advanced standards are seen more appropriate to the enterprise world. As such, we have seen Cloud providers implementing more heavyweight standards like SAML as a direct response to customer requirements. There will be ongoing debates around this question, but at the end of the day, the customer's point of view should win. As a matter of fact, it was suggested that the most effective leverage for standards adoption happens during the RFP contracting process where customers mandate specifically the support of SAML for example. It was noted that another standardization gap relates to the relative inability to get access to application audits and access logs in a coherent and secure way. This gap is rooted at the standardization bodies level defining auditing and access logs standards.

SAML v2 is sufficient and a well-adapted standard for the support of identity federation. SPML, on the other hand (or something very much like SPML), is needed for identity provisioning in the Cloud. The lack of a provisioning standard support in the Cloud is a serious concern that providers must address now to get around the plight of proprietary connectors and custom developments. Also, there are some educational problems around SPML. It is not a well-known standard across the board as its specification does not follow the same "happy path" as the SAML specification.

XACML standard adoption is more of a longer term issue and a more tricky concept for organizations to get their head around. The need for remote authorization in the Cloud will come at some point, but pressure on providers is a little further out. XACML is certainly sufficient for remote authorization in the Cloud and a very rich specification. However, business requirements aren't there yet for organizations to fully understand why they would need to externalize standards like this. There seems to be no generic use cases except perhaps in some vertical markets where specific security requirements call for remote authorization management.

Governance, risk management and compliance (GRC) in the Cloud is yet an even more complicated topic. It was suggested that the first place to go is not related to technology or standards, but to the framework of corporate policies. When trying to nail down cross-domain application relationships in the Cloud, you need a way of communicating requirements and policies at a higher level. At some point, there will be standards able to communicate that kind of information, but today it is hard to think of it as a standard. Risk management auditing is commonly happening more in isolation, in different places with different Cloud vendors implementing it their own way hoping it will become the standard. The best fall-back option may reside in control frameworks already in place in the enterprise such as COBIT or ISO 27000 These norms are most relevant to IT and business service management (ITSM) functions. However, the problem with these frameworks is that they are too broad and non-technical, hence leaving way to interpretations. COBIT provides standardized metrics for self-assessment and self-auditing that could be leveraged in technical standards for the Cloud.

Standards relevancy should be think through according to the three service models found in the Cloud - infrastructure-as-a service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS) - because these models cast different types of constraints. For example, SaaS and PaaS are black boxes from a security point of view, whereas IaaS is largely yours to apply the same security schemes and controls as you do in on-premises data centers. In any event, auditors are looking for continuity and formalization in the way they apply assessment criteria for SOX or PCI compliance, for instance, regardless whether applications run in the Cloud or on-premises.

Indeed, not all Cloud service models are equal from a security standardization adoption perspective. There are differences between IaaS, PaaS and SaaS with regard to IAM, GRC and ITSM enablement. The key point is that the amount of control you get over your Cloud-based applications goes from one where you have almost complete control with IaaS, to one where you get almost no control - technically speaking - excepted at the data level with SaaS. The question one should ask from a security control changes point-off-view is that SaaS providers should at least provide controls for managing users and their access privileges. Getting control over access logs is a must, but difficult to achieve because of the lack of standards. As you go to the PaaS model, building an application with some level of control at the application logic level is your responsibility, but beyond that level, controls are kind of murky. With IaaS you might want to keep control over privileged users because they are those who get OS access in the VM. The main difference between IaaS and an on-premises infrastructure is that you can't go to the bare-metal. The physical machine is a black box. Anything above that is your responsibility as you can control the entire software stack and, therefore, you should keep the same controls and security processes for applications running in an IaaS and applications running on-premises. However, even though there are differences in the way your applications run in the Cloud, the standards that are used for IAM and GRC should be consistent across the board regardless of the deployment model being used. That is not the case today. For example, getting SAML support in a public SaaS out of your technical control requires the provider to do it for you, whereas in IaaS, buidling SAML in your application is up to you. If you build it, you get it.

The Cloud has already affected the evolution of Web Services and SOA and standards around these technologies. For example, Salesforce.com already has more interactions with its Web Services API than it does in terms of browser interactions. Also we can see an increase of inter-cloud interactions with mashups. We have gone from a unidirectional kind of interaction to a bi-directional interaction (i.e. inbound and outbound data transfers). Again, enterprises are focusing on WS* standards whereas the Cloud focuses more on REST-based APIs, for which there wasn't, until the advent of OAuth, a good standard for identify and data security. But there is still a little bit of flux. It is still too early to say which standard to use to secure Cloud-based services because Cloud management APIs haven't stabilized enough yet to positively say which WS* or REST style approaches will prevail. Also, the emergence of the Cloud is the best thing that can happen to SOA because it is bringing under the spot light a compelling service-oriented architectural paradigm.

Cloud computing vendors are adopting IAM security and GRC standards slowly. Too slowly according to the panelists. Customers should mandate for the support of these standards at procurement time as they are the biggest adoption drivers when dealing with SaaS offerings for instance. However, this is not slowing down Cloud Computing yet because INFOSEC people are just starting to think about the security aspects of Cloud Computing and auditors who have to measure the enterprise's ITC against corporate security policies and regulatory compliance are just starting to show interest in the Cloud. These two groups will certainly start to have more influence over these problems to be addressed in a more timely and standardized manner. They will be one of the forcing factors to accelerate the deployment of these standards. At the end of day, Cloud Computing vendors will adopt established security standards only if there is a compelling business incentive for them (i.e. service differentiation, taking into account customer requirements) otherwise they won't. Therefore, the ITC security industry needs to keep pushing for this to happen in any possible way.

[1] Speakers: Matthew Gardiner - Director CA, Patrick Harding - CTO Ping Identity, Martin Kuppinger - Kuppinger Cole

Identity in the Cloud discussed at RSA Conference 2010

2010-03-17T11:31:00.000-07:00

Data security and privacy threats is often spotted as inhibitor #1 against mainstream adoption of Cloud Computing. Personally, I think that this claim is too often overly emphasized. In reality, Cloud platforms may be safer than many in-house data centers for the simple reason that many IT departments underestimate or just don't understand security risks at the level big irons like Amazon, Rackspace and others do. Anyhow, for those who didn't get the chance to attend the RSA Conference 2010 (like me), here is the link of the CA keynote panel replay discussing identity in the Cloud. Enjoy!
http://media.omediaweb.com/rsa2010/video-only.htm?id=2-5

Update on OpenSSO Authnicip

2010-02-02T03:22:00.000-08:00

Last December I posted an article about the OpenSSO's Authnicip extension module. That's the extension to issue Information Cards and Security Tokens to an Identity Selector. I said, the code doesn't compile anymore with the latest build of openinfocard and that I would try to fix it. This was easy enough, so I have done it to the best of my knowledge with no guaranty of course. However, I don't currently have the commit rights for this extension. So, until I figure that out, and for those who can't wait (I doubt it), I can send a tar file upon request.

Don't say OpenSSO, say OpenAM

2010-02-02T01:46:00.000-08:00

The news arrived on teletwitter yesterday... A new open-source shop headed by Lasse Andressen- Sun's former CTO for Central & Northern Europe-was born February 1st, 2010 under the name of ForgeRock. ForgeRock is apparently providing a "home" for OpenSSO, OpenESB and Liferay portal projects with the clever intend to ramp up the security integration stack. This is good news, not surprising, and certainly bound to happen following Oracle's announcement to pull "useful" parts (i.e. Fedlet, STS, Entitlement) out of OpenSSO to feed into Oblix without clearly indicating what's next with OpenSSO and its community. ForgeRock says "to be committed to the continued open development of OpenAM (understand OpenSSO) and aims to meet Sun's original product roadmap". That's great! Coupe things puzzle me though... How on Earth can they release OpenSSO Express Build 9 (re-branded OpenAM Build 9) today since the official bits aren't released yet? Or maybe they are, only we don't know it. And second, what engineering resources will they commit to continue the development on the basis of the OpenSSO's source tree? To be followed...

How about the OpenSSO's Information Card Issuer?

2009-11-23T01:41:00.000-08:00

How about OpenSSO as an Information Card issuer...? Some of you may have noticed the existence of an extension known as Authnicip (for Information Cards Identity Provider) in the OpenSSO extension's source code repository... Wouldn't be cool to issue Information Cards with OpenSSO? That's what this module is aimed for. As for Authnicrp (for Information Cards Relying Party) the extension relies quite a bit upon the openinfocard project to deal with the lower level protocols of the Identity Metasystem. It turns out that this code hasn't been update for 18 months, and that it doesn't compile with the latest version of openinfocard's library any more. A quick review of the code makes me optimistic that this issue can be fixed relatively easily. I'll keep you posted on my progress with some follow up articles that will explain how to use Authnicip in conjunction with Authnicrp, the Information Cards authentication module.

OpenSSO SSOToken Standard Properties

2009-11-18T08:19:00.000-08:00

That's a note for myself that can be useful to others... Thanks to Charles Wesley for the trick.
Also, you can check this link : http://docs.sun.com/app/docs/doc/820-3748/adudc?a=view.
Always look at the documentation before asking silly questions...

CharSet: ex. "UTF-8"
UserId: ex "fb"
FullLoginURL: ex. "/opensso/UI/Login?module=LDAP"
successURL: ex. "/opensso/console"
cookieSupport: ex. "true"
AuthLevel: Ex. "0"
SessionHandle: ex. "shandle:"
UserToken: ex. "upgradeuser"
loginURL: ex. "/opensso/UI/Login"
IndexType: ex. "module_instance"
Principals: ex. "uid=foobar,ou=people,dc=red,dc=iplanet,dc=com"
moduleAuthTime: ex. "LDAP+2009-11-10T20:38:16Z|anon1+2009-11-10T20:37:44Z
amlbcookie: ex. "01"
sun.am.UniversalIdentifier: ex. "id=foobar,ou=user,dc=red,dc=iplanet,dc=com"
Organization: ex. "dc=red,dc=iplanet,dc=com"
Locale: ex. "en_US"
HostName: ex. "red.iplanet.com"
com-iplanet-am-console-location-dn: ex. "dc=red,dc=iplanet,dc=com"
AuthType: ex. value="LDAP|anon1"
UserProfile: ex. "Required"
Host: ex. "red.iplanet.com"
clientType: ex. "genericHTML"
AMCtxId: ex. "6747059ed30ea08a01"
authInstant: ex. "2009-11-10T20:38:16Z"
Principal: ex. "uid=upgradeuser,ou=people,dc=red,dc=iplanet,dc=com"

Claims-based Identity in OpenSSO (Part III)

2009-10-14T08:29:00.000-07:00

In Claims-based Identity in OpenSSO (Part II) I talked about how to use an Information Card to sign-in within OpenSSO using the ignore user profile. In this post, I will show how the Information Card Module (a.k.a the Authnicrp Module ) and OpenSSO's core services can be configured to perform claims-based access control and self-provisioning actions using the dynamic user profile. Simply put, the required or dynamic profiles require that an active user account exist in the OpenSSO's Identity Repository in order to authenticate a subject successfully, and this regardless of whether the subject's Information Card meets the security requirements of the Relying Party (RP) or not.

Self-Provisioning

In addition, the dynamic user profile allows for dynamically provision a new user account (when one doesn't exist or is not associated with an Information Card yet) using the Information Card's claims. As always, it is up to the subject to decide what optional claims can be shared or not with the RP during the sign-up process. This feature is referred to as claims-based self-provisioning, whereby the administrator defines claim to attribute mapping rules as shown in the configuration pane below:

Exact mapping rules may differ from one Identity Repository to another. For example, OpenDS and Active Directory have significant different schemas, thus requiring different attribute names to Information Card claims mapping rules.

In the required or dynamic profiles, the Authnicrp module link a user account with one or more Information Cards (when they are presented for the first time to the module) using the Personal Private Identifier (PPID). This association is performed under two conditions: 1) the user is successfully authenticated with regular username / password credentials or creates a new account, 2) the claims contained in the security token match the security requirements of the Relying Party (RP). Once the binding is completed, any Information Card associated with a user account can be used for sign-in, in lieu of the username / password credentials, until the card expires or is removed from the account.

Claims-based Access Control

The Authnicrp module offers also the possibility to link a self-provisioned user account with an LDAP group or role. This capability is achieved through the creation of a role-resolver-plug-in that is declared in the Authnicrp module's configuration pane as shown in the figure below.

In this case, the ComeOfAge plug-in is invoked by Authnicrp every time an Information Card is presented. The function of the plug-in is to return 'true' whenever the digital identity of the subject matches the criteria of ComeOfAge role or 'false' otherwise. It is up to the developer of the role-resolver-plug-in to implement the matching logic that is appropriate.

An administrator can set up as many role-resolver-plug-ins as necessary in a module instance for the task at hand. Each plug-in is invoked in sequence by the Authnicrp module. Typically, a role-resolver-plug-in implements the RoleCheckPlugin interface that has only one method:

boolean isIdentityMatchingRole(InfocardIdentity identity, String role);

The two short videos below show the onscreen sign-in and sign-up experiences for a user of an Information Card. The browser window on the left points to a website protected by a Security Agent executing different security policies. The browser window on the right points to the OpenSSO's administration console.

To access the protected.jsp resource, the user must be successfully authenticated
To access the comeOfAge.jsp resource, the user must be successfully authenticated and must possess the ComeOfAge role
To access the corporate.jsp resource, the user must be successfully authenticated and must belong to the group 'employee' in Identity Repository for the realm. Self-provisioning is used to dynamically create a new user account.

To display the video, click on the images below (please use full screen mode)

Information Card and OpenID Foundations to collabortate on the Open Trust Framework

2009-10-10T00:22:00.000-07:00

Mary Rudy of the Information Card Foundation (ICF) announced recently a joint effort with the OpenID Foundation (OIDF) to collaborate on the Open Government Initiative that will enable the US government to accept Information Cards and OpenIDs from industry identity providers.

At Gov 2.0 last month, Vivek Kundra, the Federal CIO, announced a pilot project to have government websites accept industry identity credentials. The Information Card and OpenID foundations issued a joint press release naming ten industry Identity Providers and the National Institutes of Health (NIH) as the first agency to participate in a pilot project.

"As part of enabling this initiative, the ICF has worked closely with the US General Services Administration (GSA) Identity Credential and Access Management (ICAM) committee to define profiles of the Information Card IMI 1.0 standard for use by US government websites for levels of Assurance 1-3. In order for US government websites to know which IdPs conform to the GSA’s profile and privacy policies, the GSA is requiring that IdPs be certified" said Mary Ruddy.

To that aim, the ICF and OIDF are collaborating to create an Open Trust Framework program that can perform this certification. The Open Trust Framework is explained in the joint white paper Open Trust Frameworks for Open Government.

Net-ID 2009 is over

2009-10-04T02:58:00.000-07:00

Special thanks to Stefanie Schiebenhoefer and team at Computas, as well as Hellmut Broda for the excellent and friendly organization of Net-ID 2009. I wish I had better managed my time to run a more complete demo of the OpenSSO Information Cards module... But for those interested, there is one screencast and more to come on this topic in the "Claims-based Identity in OpenSSO" series. It was particularly impressive to meet and hear in person some of the big names of the Identity Management sphere like Gerry Gebel, from Burton Group, whom I am an assiduous reader.

Claims-based Identity in OpenSSO (Part II)

2009-09-27T22:30:00.000-07:00

In Claims-based Identity in OpenSSO (Part I), I started with introducing briefly the concept of claims-based identity, and how to configure and use the Information Cards authentication module (a.k.a Authnicrp module) of OpenSSO. In this post, I discuss further the behavior of the Authnicrp module when the 'Ignore' user profile of the Core authentication service is used.

In this user profile, the Authnicrp module provides anonymous access to resources protected by a Security Policy Agent. The term 'anonymous' here tends to be a misnomer as it refers to OpenSSO's anonymous access that allows to log on without presenting credentials. However, Information Cards identities are anonymous so long as one's claims do not allow others to know one’s personal identity. Furthermore, the Authnicrp module does not necessarily eliminate the need to present authentication credentials. To get a security token, a user is required to authenticate one way or another (e.g. password, X509 certificate, Kerberos, self-signed i-card), through the Identity Selector, for the Identity Provider (IDP) to assert the claims presented in the security token. This requirement can be enforced by configuring the module not to allow self-signed information cards for example. Hence, the level of trust a Relying Party (RP) puts in Information Cards will depend on the method used by the IDP to collect personal information, and the authentication schemes used to challenge the identity of a user.

The administrator must specify an anonymous user ID in a realm, so that anyone in that realm can log on with an information card provided the asserted claims honor the security requirements of the Relying Party (RP). The reason why we need a user ID with Information Cards is purely technical. An OpenSSO authentication module is a JAAS module, and as such, is required to return a subject's Principal. If the authentication succeeds, a session is created for the user ID that stores the claims and their values as property value-pairs. Session properties are retained in the system until the user's session expires. In a future post, I will explain how applications can retrieve session properties either by way of querying the Session Service, or by way of configuring the Security Policy Agent to copy them in various HTTP artifacts.

The anonymous mode provides several benefits. It allows to grant access to an information card bearer, while avoiding the usual tedious registration process of creating a user account. Also, because Information Cards supply claim values such as name, address, and e-mail address to RPs on demand, Web sites do not need to store persistent personal data. This way, the anonymous mode reduces the need for Web sites to request and store personal data across sessions and thereby narrows a classic attack vector for identity theft.

The short video sequence below shows the onscreen user's experience of getting access to a protected resource using an information card in anonymous mode. The sequence is as follow:

The user hits a Web page with a link to a protected resource
The user presents a self-signed i-card with a blank email-address required claim
The Authnicrp denies access but gives the user a second chance
The user this time uses another i-card that has all required claims filled in
OpenSSO grants access to the protected resource that displays some of the information cards claims retrieved from the HTTP request

Information Cards in OpenSSO at Net-ID 2009

2009-09-24T10:20:00.000-07:00

I got the opportunity to talk about Information Cards in OpenSSO at Net-ID 2009. For those interested to attend the conference, you can get 50 % discount by using 'STG' code in the registration page.

Claims-based Identity in OpenSSO (Part I)

2009-08-18T02:20:00.000-07:00

I will discuss in a series of articles the use of the Information Cards Authentication Module (a.k.a Authnicrp extension module) version 1.0 beta that I committed recently to the OpenSSO source tree. Authnicrp is an extension of the OpenSSO core platform.

Authnicrp allows a Relying Party (RP) to accept Information Cards for a user's authentication and authorization to access Web resources protected by a Security Policy Agent. In this version, the processing of the security token is delegated to the OpenInfocard library that has been slightly modified to be embedded in the module. You should check the README file, which contains instructions for building and installing the module in an OpenSSO instance.

Backgrounder

A claim is a piece of information about a subject that an Identity Provider asserts about that subject. In the world of claims-based identity, a digital identity is simply represented by a security token that contains one or more claims, each of which carries some piece of information about the user the token identifies, such as name, age, address, employers, and the like. Claims can represent pretty much anything about a user depending on what is required by the RP services. Claims-based identity is a powerful concept that stems from the work of Microsoft on the Identity Metasystem and Information Cards (CardSpace in Microsoft's parlance). For a complete description of the concept, I recommend reading David Campbell's white paper "Introducing Geneva". There is also an Information Card Foundation dedicated to making the Information Card technology successful, which has documentation, best practices and references to contributions for Replying Party and Identity Selector software. Several open-source initiatives are being developed to facilitate the adoption and use of claims-based identity, spanning both the enterprise and the Internet ecosystems.

The Authnicrp Authentication Module at a Glance

In order to understand the Authnicrp authentication module, it is important to understand that it combines the functionalities of three other OpenSSO authentication modules. Namely, the Membership, Anonymous and Data Store standard modules. With Authnicrp, it is possible, using an Information Card, to:

login as an anonymous user,
create a user account dynamically based on the mapping of the claims provided in the security token,
login as a user registered in the data store of OpenSSO's Identity Repository (Generic LDAPv3, Sun DS with OpenSSO schema, Active Directory or JDBC database).

The operating mode is selectable from the "Realm Attributes" configuration pane of the Core authentication service as shown in the image below:

In the User Profile radio button selection you should tick:

'Ignored' for anonymous user login
'Required' for a registered user login
'Dynamic' for the dynamic creation of a user account if the account doesn't already exist

The Authnicrp Service Configuration Pane

The Authnicrp service configuration pane contains parameters that enable the module to operate according to the authentication profile chosen and the security requirements of the RP.

General Settings:

Assign a user ID to the anonymous profile
Assign default roles applied to the dynamic creation profile
Assign a status to the subject
Assign an authentication level to the service instance
The application server's keystore settings used to get the Web site's private key used to process the encrypted security token.

RP Security Requirements

The security requirements stated by the RP are entirely configurable at the realm level. Here, the site administrator can specify the list of required claims and optional claims. Verification elements defined in the claims catalog of the Information Card Foundation can also be specified, including the method employed for verifying the verified claims.

Dynamic Creation of a User Account

The Dynamic profile is used for self-provisioning of new user accounts using the claims of the security token. The configuration pane provides a flexible mechanism by which the administrator can define a claim to Identity Repository attribute mapping. It is also possible to define a set of default roles, or even better, provide a role DN to a role check-in pluggin that will be instantiated by the authentication module for determining whether the digital identity matches the requirements of a given role or not. The class "com.identarian.infocard.opensso.rp.rcheck.ComOfAge", provided in the module, gives an example of how a pluggin can be specified to check the matching programmatically. In the particular case of the ComeOfAge role, the pluggin returns true if any of the age-18-or-over, or coppa-certified-adult claims are provided in the security token.

That's it for today. Claims-based Identity in OpenSSO (Part II) will show how the anonymous profile works, and how to obtain the user's claims from OpenSSO in a Web application.

Back from vacation in Bali with new resolutions

2009-08-14T01:53:00.000-07:00

It's been a year I haven't touched this blog. Not for the lack of having things to tell. But eh, I have been really busy with work, and my MBA at GGSB, not to mention turmoil raised by the economic downturn and the Oracle-Sun M&A.

I cleaned up a little bit the presentation of this page, and changed the banner with a photo of Barong, a mythical character of Balinese theater, that I took in Bali hoping he will bring me luck and wisdom...

After two years, the taught part of the MBA program is behind me :-). So, I figured, it would be cool to share my findings here as I progress through the master thesis work. The objective of the thesis is to deep dive into analyzing the business opportunities and impediments of cloud computing from the point of view of small and medium businesses. I already collected a large number of articles and studies stating the issues from both technological and business angles. I may publish my bibliography if I get enough interest.

Also, there are obvious synergies and complementarity between what I am doing at Sun, and the subject of the master thesis. For example, I stumbled recently on an article "Identity as a service becomes reality", and a couple white papers from Conformity, discussing the challenges and risks associated with integrating SaaS and cloud-based applications into exiting IT with regard to how how this trend is fundamentally changing the traditional models of IT over control, accountability and best practices with information and operation security around segregation-of-duties, role-based access control (RBAC), and the principle of least privilege.

It will very interesting to discuss in future messages how OpenSSO's Express 9 Entitlement Enforcement capabilities can be leveraged to address some of the above issues.

Finally, I released recently an update of the Information Card authentication module for OpenSSO which is a complete a revamp of the initial version. Check the extension's README file for details. I will discuss and show in future messages how the Information Card extension can be used to enable claim-based authentication and authorization in OpenSSO.

Sounds like a good blogging program for the next few months. Let's try to stick with that.

Identity and Access in Microsoft Architecture Journal

2008-08-25T05:16:00.000-07:00

Browsing through one of my favorite blogs, I stumbled upon an astonishing issue of the Microsoft Architecture Journal, which talks about Identity and Access. This issue is full of information about user-centric and digital identity, federation, STS and more. A must read to get an overview of the state-of-the-art!

How to insert source code in a blog post

2008-08-19T00:56:00.000-07:00

I have been struggling quite a bit with this question until I find the link Displaying Java Code or HTML code in Blogger.

OpenSSO tips and tricks: Install and Configure the AgentSample

2008-08-18T06:21:00.000-07:00

Asyd's Blog published a post in French about how to install and configure the agentsample.

OpenSSO tips and tricks: Backup the embedded OpenDS

2008-08-18T06:15:00.000-07:00

Asyd's Blog published post in French about how to backup the OpenDS configuration database embedded in OpenSSO.

The OpenSSO Information Card RP extension works fine with build 5

2008-08-12T02:13:00.000-07:00

Yesterday, I successfully tested the Information Card Relying Party authentication module (authnicrp extension) against OpenSSO Express Build 5. Introduced a minor fix in the handling of the Information Card parameters, and new 'install' ant target that allows to install the extension in a deployed OpenSSO instance more easily.

Sun Microsystems to provide OpenSSO Support

2008-08-08T02:16:00.000-07:00

Sun Microsystems announced on July 23, 2008 support for OpenSSO through its Sun OpenSSO Express program. What it means is that companies can buy support for the OpenSSO offering that is expected to release on a much shorter cycle basis than its commercial counterpart Federated Access Manager (now rebranded Sun OpenSSO Enterprise). That's a good news for OpenSSO contributors and customers who should be able to access new features issued from the OpenSSO community quicker than waiting for the longer full releasing cycles of Federated Access Manager.

OpenSSO Information Card Extensions Demo at Concordia Workshop RSA 2008

2008-04-08T01:58:00.000-07:00

Pat Patterson announced yesterday that the RSA IOP scenario, held Monday, April 7, 2008, featured the Information Card RP and IdP/STS extensions of OpenSSO. Notes from the Concordia workshop still to be supplied. I believe Pat did some enhancements to the Information Card RP authentication module to support the declaration of dynamic claims passed directly in the request URI. More on this latter... Further I3 user-centric identity interoperability demonstrations will be held Tuesday, April 8 and Wednesday, April 9, 2008 at the Moscone Center. So, Pat, we are counting on you to let us known how things worked out.

Writing a Relying Party for the OpenSSO Information Card Authentication Module

2008-04-07T01:09:00.000-07:00

This post explains how to write a simple relying party web application using the Information Card Authentication Module extension of OpenSSO. This is two simple steps detailed below:

Install and setup the Information Card Authentication Module following the instructions outlined in the README file.
Create a web application that will use the Client SDK for Java.

Once you have created your web application project, using Netbeans for instance, you need to add the Client SDK for Java in the project's libraries property. If you installed OpenSSO, the jar file is located under install-dir

/libraries/jar/openssoclientsdk.jar

Then, you'll need to prepare the AMConfig.properties file which contains parameters used by the SDK to connect to the OpenSSO services. You can do it either manually (the hard way), or deploy the samples web application provided in

install-dir/samples/war/fam-client-jdk15.war.

First, unzip fam-client.zip and then deploy the WAR file. This web application invokes a JSP (i.e. Configurator.jsp), which creates a AMConfig.properties file in the user's home directory. Personally, I used the defaults for user name and password (i.e. anonymous) which happened to work fine for my needs. This part is little a tricky but not unsurmountable. This unfortunate convolution comes from the lack of an installer and specific documentation, that are included with Access Manager, but not with the open source project.

You can verify that the AMConfig.properties is properly configured by playing with the samples web application. Once you get there, writing and deploying a relying party web application using the Information Card authentication module is fairly easy. Here is an example that I provided for your convenience. Create a servlet in your project and copy the file below. It should work...


package com.identarian.infocard.opensso.ssosample;

import com.iplanet.am.util.SystemProperties;
import com.iplanet.sso.SSOException;
import com.iplanet.sso.SSOToken;
import com.iplanet.sso.SSOTokenListener;
import com.iplanet.sso.SSOTokenManager;
import com.sun.identity.idm.AMIdentity;
import com.sun.identity.idm.IdRepoException;
import com.sun.identity.idm.IdUtils;
import java.io.*;
import java.net.*;

import java.util.Map;
import java.util.Properties;
import javax.servlet.*;
import javax.servlet.http.*;

/**
 *
 * @author ppetit
 */
public class SSOTokenSample extends HttpServlet {

    private static boolean initialized = false;
    private static String host = null;
    private static String port = null;
    private static String proto = null;
    ServletOutputStream out = null;

    @Override
    public void init() {

        String configFile = System.getProperty("user.home")  
                File.separator   "AMConfig.properties";
        Properties props = new Properties();
        try {
            props.load(new FileInputStream(configFile));
        } catch (IOException e) {
            System.out.println("Failed to load AMConfig.properties");
            return;
        }

        host = props.getProperty("com.iplanet.am.server.host", "localhost");
        port = props.getProperty("com.iplanet.am.server.port", "8181");
        proto = props.getProperty("com.iplanet.am.server.protocol", "https");

        SystemProperties.initializeProperties(props);


        initialized = true;
    }

    /** 
     * Processes requests for both HTTP <code>GET</code> and <code>POST</code> methods.
     * @param request servlet request
     * @param response servlet response
     */
    protected void processRequest(HttpServletRequest request,
            HttpServletResponse response)
            throws ServletException, IOException {

        response.setContentType("text/html;charset=UTF-8");

        try {
            out = response.getOutputStream();

            // create the sso token from http request 
            SSOTokenManager manager = SSOTokenManager.getInstance();
            SSOToken token = manager.createSSOToken(request);
            out.println("Entering SSOTokenSample.java");
            out.println("<br />");
            // throws an exception if token is not valide
            manager.validateToken(token);
            //print some of the values from the token.

            java.security.Principal principal = token.getPrincipal();
            String authType = token.getAuthType();

            out.println("SSOToken Principal name: "  
                    principal.getName());
            out.println("<br />");
            out.println("Authentication type used: "   authType);
            out.println("<br />");

            // Retrieve user profile and print them
            AMIdentity userIdentity = IdUtils.getIdentity(token);
            Map attrs = userIdentity.getAttributes();
            out.println("User Attributes: "   attrs);
            out.println("<br />");
            // Retreive user session properties
            out.println("Session properties:");
            String ppid = token.getProperty("privatepersonalidentifier");
            if (ppid != null && ppid.length() != 0) {
                out.println("PPID: "   ppid);
            }
            String gname = token.getProperty("givenname");
            String sname = token.getProperty("surname");
            if (gname != null && sname != null) {
                out.println("Welcome "   gname   " "   sname);
            }
            out.println("<br />");
            /*
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
            <PARAM Name="optionalClaims"            Value="
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender
           
            http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
             */
            /* let us add a listener to the SSOToken. Whenever a token
             * event arrives, ssoTokenChanged method of the listener will
             * get called.
             */
            SSOTokenListener myListener = new SampleTokenListener();
            token.addSSOTokenListener(myListener);
        } catch (SSOException e) {
            // No valid SSO token in request redirect to Infocard authh module
            String openssoUrl = proto   "://"   host   ":"   port  
                    "/opensso/UI/Login?module=Infocard&goto="  
                    request.getRequestURL().toString();
            response.sendRedirect(openssoUrl);
        } catch (IdRepoException e) {
            out.println("IdRepo Exception: "   e);
            e.printStackTrace();
        } catch (IOException e) {
            out.println("IO Exception: "   e);
            e.printStackTrace();
        } finally {
            out.flush();
        }

    }

    /** 
     * Handles the HTTP <code>GET</code> method.
     * @param request servlet request
     * @param response servlet response
     */
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    /** 
     * Handles the HTTP <code>POST</code> method.
     * @param request servlet request
     * @param response servlet response
     */
    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    /** 
     * Returns a short description of the servlet.
     */
    @Override
    public String getServletInfo() {
        return "SSOTokenSample servlet demonstrate the use of OpenSSO client SDK";
    }
    // </editor-fold>
}

[1] Client SDK configuration properties loaded from AMConfig.properties
[2] Initialize the SDK with properties
[3] Test whether a valid token is present in the request or not
[4] Display user's identity repository data, that is only the uid / password in the case
of Information Card authentication module
[5] Display Information Card claims stored in the session by the module
[6] An SSOException is thrown because the token is invalid. The catch block sends a redirect to the Information Card auth module, which in turn, sends the user back (notice the goto) to the RP's current URL when the authentication is complete

Information Card Authentication Module with OpenSSO Build 4

2008-04-04T02:42:00.000-07:00

I upgraded to OpenSSO Build 4 this morning to test the Information Card Relying Party authentication module (i.e. authnicrp OpenSSO extension). I did some changes that I committed to the opensso/extension build yesterday. The changes improve the configurability and security of the module, thanks to Axel's explanation about the use of the Token.getClientDigest() method of the xmldap.org library. Also, notice that you will have to recompile xmldap-1.0.jar with the latest of xmldap.org build to get a fix for this method and run the Information Card authentication module.

OpenSSO Build 4 is out-of-the-door

2008-04-03T06:13:00.000-07:00

OpenSSO build 4 availability was announced earlier this week on The Aquarium with a support for WS-Trust based Security Token Service (STS) (based on Metro).

Higgins Tutorial and Short Talks at EclipseCON on March 17-19

2008-03-13T07:04:00.000-07:00

Mary Ruddy,from SocialPhysics.org, just announced that a tutorial on Higgins will be presented on Monday at EclipseCON March 17-20 2008 at the Santa Clara Convention center.
The presentation can be downloaded here.

Information Card Relying Party Authentication Module for OpenSSO

2008-02-29T08:26:00.000-08:00

Things always come at once. Now I have to setup a blog to get the most out of publishing an OpenSSO extension which supports Information Card authentication. Superpat, kindly posted a nice article on the Aquarium about the event. I think that combining the power and staggering capabilities of OpenSSO along with a standardized authentication module supporting Information Card a.k.a Cardspace or Infocard should facilitate the adoption of the technology in the enterprise.