Movember at ForgeRock

I heard of the Movember movement last year when my friend Pat aka @Metadaddy filled my twitter stream with his moustachy face. I quickly noticed other people growing a moustache, including the Grenoble hockey team : Les Bruleurs de Loups.

So this year, when Andrew Forrest suggested that we create a ForgeRock team for Movember, I didn’t hesitate much, joined, and recruited other coworkers for the French team. I told my wife beforehand and she was not really enthusiastic about the idea of a moustache on my face. But my middle daughter was encouraging me to participate and help improve men’s health research and awareness.

mo_strip

 

We’re reaching the end of Movember, and the moustache has grown. My wife hates it… So help me proving her that it was worth suffering and make a donation to our team.


Filed under: General Tagged: charity, ForgeRock, health, men, moustache, Movember, team

OpenDJ Contact Manager for Android

With OpenDJ 2.6.0, we’ve introduced a new way to access your directory data, using HTTP, REST and JSon. The REST to LDAP service, available either embedded in the OpenDJ server or as a standalone web application, is designed to facilitate the work of application developers. And to demonstrate the interest and the ease of use of that service, we’ve built a sample application for Android : the OpenDJ Contact Manager

OpenDJ Contact Manager Android AppAbout screen of the OpenDJ Contact Manager Android App

The OpenDJ Contact Manager is an open source Android application that was built by Violette, one of the ForgeRock engineer working in the OpenDJ team. You can get the source code from the SVN repository : https://svn.forgerock.org/commons/mobile/contact-manager/trunk. Mark wrote some quite complete documentation for the project, with details on how to get and build the application. He published it at http://commons.forgerock.org/mobile/contact-manager/.

The whole application is just about 4000 lines of code, and most of it is dealing with the display itself. But you can find code that deals with asynchronous calls to the OpenDJ rest interface, with paging through results, and parsing the resulting JSON stream to populate the Contacts, including photos. Et voila :

OpenDJ Contact Manager displaying a Contact

The application is just a sample but it clearly is usable in its current form and will allow once a contact was retrieved from the OpenDJ directory, to add it to the Contacts standard application, call the person, locate its address on maps, send the person an email, navigate through the management chain…

In future versions, we are planning to add support for OAuth 2.0, removing the need to store credentials in the application settings.

As it’s open source, feel free to play with it, hack and contribute back your changes.


Filed under: Directory Services Tagged: Android, directory-server, ForgeRock, identity, java, Json, ldap, Mobile, opendj, opensource, REST

OAuth2 – The Passwordless World of Mobile

Keeping in vogue with the fashion of killing off certain standards, technology or trends, I think it's an easy one to say, that the life of the desktop PC (and maybe even the laptop...) is coming to an end.
Smartphone sales are in the hundreds of millions per quarter and each iteration of both the iOS and Android operating system brag of richer user experiences and more sophisticated storage and app integration.  The omnipresent nature of these powerful mini-computers, has many profound benefits, uses and user benefits.



Mobile Weakness + Password Weakness = Nightmare!

With anything in the information world that is popular, comes with it security weaknesses and vulnerabilities.  The popularity aspect is a big trigger for the generation of malware and criminal intent.  As a malware developer, you would want the reward ration to be as high as possible, which means developing exploits for devices and operating systems that are the most popular.  Some key aspects of all mobile devices however result in general security weakness.  Firstly, they're small, meaning they can be easily lost or stolen.  That weakness is pretty difficult to overcome.  Unfortunately as mobiles now hold significant personal and professional information, emails, attachments, cached passwords and so on, a physical loss can have significant impact.  Most mobile devices carry no real form of anti-virus or anti-malware software, albeit this is improving.

Passwords as we know, are now not regarded as a secure means to protect websites and applications.  End users don't tend to select complex passwords (if they do they are written down...) and the transport and storage of such passwords (lack of encrypted channels, passwords not hashed in storage) all contribute to more instances of password leaks and compromise.

Password use on mobile phones, then introduces a mixture of potential vulnerabilities.  Mobile users want to access protected applications, social networking sites and web sites, all with email address and password based authentication.

Mobile keyboards are small, so many will simply enter the credentials once and cache them, leaving them vulnerable to reuse and capture if the device is lost or the operating system compromised.


Introduce OAuth2

OAuth2 (not to be confused with OAuth or OATH...) is making great strides in being the defacto standard authorization protocol, for web applications and modern federated services.  OAuth2 provides a neat access and refresh token approach to giving access to sites and services, which can reduce the burden of using static username and password based authentication and authorisation.  At a high level, OAuth2, can issue both an access token and refresh token, along with what is known as a scope.

The access token does what it says, and generally has a small lifespan - perhaps only a few minutes. The refresh token on the other hand, may have a longer lifespan and can be exchanged for a new access token in the future, without the need to re-enter usernames or passwords.  The benefit being, that the OAuth2 authorization server, can revoke the refresh token if the device that holds it, is compromised or lost. A significant improvement on having to reset passwords if a mobile is lost and contains cached passwords.  The scope aspect is simply a list of permission attributes that the authorisation server attaches to the associated access token before releasing to the requesting resource.

OAuth2 provides several different mechanisms for releasing tokens (called grants) which I wont go into here, but ultimately there is less reliance on the repeated entry of usernames and passwords.  The use of tokens removes the need for the caching of such credentials and also does not require credential exchange between the authorisation service and the protected resource.

By being able to remotely revoke an access or refresh token, gives the identity owner much more control in the event that a physical device is lost, stolen or compromised.

In addition, as passwords would be required less, more complex passwords can be used (created using generators) in order to provide a little more protection.

By Simon Moffatt





OAuth2 – The Passwordless World of Mobile

Keeping in vogue with the fashion of killing off certain standards, technology or trends, I think it's an easy one to say, that the life of the desktop PC (and maybe even the laptop...) is coming to an end.
Smartphone sales are in the hundreds of millions per quarter and each iteration of both the iOS and Android operating system brag of richer user experiences and more sophisticated storage and app integration.  The omnipresent nature of these powerful mini-computers, has many profound benefits, uses and user benefits.



Mobile Weakness + Password Weakness = Nightmare!

With anything in the information world that is popular, comes with it security weaknesses and vulnerabilities.  The popularity aspect is a big trigger for the generation of malware and criminal intent.  As a malware developer, you would want the reward ration to be as high as possible, which means developing exploits for devices and operating systems that are the most popular.  Some key aspects of all mobile devices however result in general security weakness.  Firstly, they're small, meaning they can be easily lost or stolen.  That weakness is pretty difficult to overcome.  Unfortunately as mobiles now hold significant personal and professional information, emails, attachments, cached passwords and so on, a physical loss can have significant impact.  Most mobile devices carry no real form of anti-virus or anti-malware software, albeit this is improving.

Passwords as we know, are now not regarded as a secure means to protect websites and applications.  End users don't tend to select complex passwords (if they do they are written down...) and the transport and storage of such passwords (lack of encrypted channels, passwords not hashed in storage) all contribute to more instances of password leaks and compromise.

Password use on mobile phones, then introduces a mixture of potential vulnerabilities.  Mobile users want to access protected applications, social networking sites and web sites, all with email address and password based authentication.

Mobile keyboards are small, so many will simply enter the credentials once and cache them, leaving them vulnerable to reuse and capture if the device is lost or the operating system compromised.


Introduce OAuth2

OAuth2 (not to be confused with OAuth or OATH...) is making great strides in being the defacto standard authorization protocol, for web applications and modern federated services.  OAuth2 provides a neat access and refresh token approach to giving access to sites and services, which can reduce the burden of using static username and password based authentication and authorisation.  At a high level, OAuth2, can issue both an access token and refresh token, along with what is known as a scope.

The access token does what it says, and generally has a small lifespan - perhaps only a few minutes. The refresh token on the other hand, may have a longer lifespan and can be exchanged for a new access token in the future, without the need to re-enter usernames or passwords.  The benefit being, that the OAuth2 authorization server, can revoke the refresh token if the device that holds it, is compromised or lost. A significant improvement on having to reset passwords if a mobile is lost and contains cached passwords.  The scope aspect is simply a list of permission attributes that the authorisation server attaches to the associated access token before releasing to the requesting resource.

OAuth2 provides several different mechanisms for releasing tokens (called grants) which I wont go into here, but ultimately there is less reliance on the repeated entry of usernames and passwords.  The use of tokens removes the need for the caching of such credentials and also does not require credential exchange between the authorisation service and the protected resource.

By being able to remotely revoke an access or refresh token, gives the identity owner much more control in the event that a physical device is lost, stolen or compromised.

In addition, as passwords would be required less, more complex passwords can be used (created using generators) in order to provide a little more protection.

By Simon Moffatt





LDAPCon 2013 – a summary…

ldapcon_2013_logo_line_dateLast Monday and Tuesday (Nov 18-19), I was in Paris attending the 4th International LDAP Conference, an event I help to organize with LDAPGTF, a network of French actors in the LDAP and Identity space. ForgeRock was also one of the 3 gold sponsors of the conference along with Symas and Linagora.

LDAPCon 2013The conference happens every other year and is usually organized by volunteers from the community. This year, the French guys were the most motivated, especially Clément Oudot from Linagora, leader of the LDAP Tool Box and lemonLDAP projects, and Emmanuel Lecharny one of the most active developers on Apache Directory Server.

I was honored to be the keynote and first speaker of the conference and presented “The Shift to Identity Relationship Management“, which was well received and raised a lot of interest from the audience.

The first day was focusing more on the users of LDAP and directory services technologies, and several presentations were made about REST interfaces to directory services, including the standard in progress: SCIM.

Kirian Ayyagari, from the Apache Directory project, presented his work on SCIM and the eSCIMo project. Present for the first time at LDAPCon, Microsoft’s  Philippe Beraud spoke about Windows Azure Active Directory and its Graph API. And I talked about and demoed the REST to LDAP service that we’ve built in OpenDJ. For the demo, I used PostMan, a test client for HTTP and APIs, but also our newly open sourced sample application for Android : OpenDJ contact manager. In the afternoon, Peter Gietz talked about the work he did around SPML and SCIM leveraging OpenLDAP access log.

After many talks about REST, we had a series of talk around RBAC. Shawn McKinney presented the Fortress open source IAM project and more specifically the new work being done around RBAC. Then Peter, Shawn and Markus Widmer talked about the effort to build a common LDAP schema for RBAC. And Matthew Hardin talked about the OpenLDAP RBAC overlay bringing policy decisions within the directory  when deploying Fortress.

Then followed presentations about local directory proxy services for security based on OpenLDAP, about Red Hat FreeIPA (another first appearance at LDAPCon) and about OpenLDAP configuration management with Apache Directory Studio. Also Stefan Fabel came all the way from Hawaii ( Aloha ! ) to present a directory based application for managing and reporting publications by a university: an interesting story about building directory schema and data model.

The day ended with a presentation from Clement Oudot about OpenLDAP and the password policy overlay. As usual, talking about the LDAP password policy internet-draft raises the question of when it will be finally published as an RFC. While there is a consensus that it’s important to have a standard reference document for it, I’m failing to see how we can dedicate resources to achieve that goal. Let’s see if someone will stand up and take the leadership on that project.

After such a long day of talks and discussion, most of the attendees converged to a nearby pub where we enjoyed beers and food while winding down the day through endless discussions.

The second day of LDAPCon 2013 was more focused on developers and the development of directory services. It was a mix of status and presentations of open source directory projects like OpenDJ, OpenLDAP or LSC, some discussions about backend services, performance design considerations and benchmarks, a talk about Spring LDAP… As usual, we had a little bit of a musical introduction to Howard Chu‘s presentation.

LP0_1068I enjoyed the Benchmark presentation by Jillian Kozyra, which was lively, rational and outlining the major difference between open source based products and closed source ones (although all closed source products were anonymized due to license restrictions). It’s worth noting that Jillian is pretty new in the directory space and she seems to have tried to be as fair as possible with her tests, but she did say that the best documented product and the easiest one to install and deploy is OpenDJ. Yeah !!! :-)

Another interesting talk was Christian Hollstein‘s about his “Distributed Virtual Transaction Directory Server“, a telco grade project he’s working on to serve the needs of the 4G network services (such as HSS, HLR…). It’s clear to me that telco operators and network equipment providers are now all converging to LDAP technologies for the network and this drives a lot of requirements on the products (something I knew since we started the OpenDS project at Sun, kept in mind while developing OpenDJ, even though right now our focus has mainly been on the large enterprises and consumer facing directory services).

All the slides of the conference have been made available online through the LDAPCon.org website and the Lanyrd event page. Audio has also been recorded and will be made available once processed. And as usual, all the photos that I took during the conference are publicly available in my Flickr LDAPCon 2013 Set. Feel free to copy for personal use.

It’s been a great edition of the LDAPCon and I’m looking forward to the next one, in 2 years !

Meanwhile I’d like to thanks the sponsors, all 75 attendees, the 19th speakers and the 2 organizers I had not mentioned yet : M.C. Jonathan Clarke and Benoit Mortier.


Filed under: Directory Services Tagged: conference, directory, directory-server, ForgeRock, france, identity, ldap, ldapcon, opendj, Paris, photography

A Sample OpenIG configuration showing Tomcat Login



ForgeRock's  Open Identity Gateway (OpenIG) is a "smart" reverse proxy interacts with the HTTP session to modify headers, cookies, and the body.

A common OpenIG  use case is to SSO enable legacy applications that can not be modified to use a policy agent.

The way this works is described in the gateway guide but the readers digest version is:
  • OpenIG itself is protected with an OpenAM policy agent
  • OpenAM's password capture post authentication handler is configured to capture the user's password on login, and provide it (encrypted) to OpenIG. 
  • OpenIG is configured to watch for an HTTP request to the legacy application's login page
  • When OpenIG sees the login page it injects the users credentials into the login flow. 
The guide has a few examples for Wordpress login - but I wanted to demonstrate login to Tomcat. 

This OpenIG config.json file is configured to SSO into the sample form login demo that included with tomcat (/examples/jsp/security/protected).

This config.json assumes:

  • A tomcat instance is running on port 48080 with the sample application. This is our "legacy" application.
  • tomat-users.xml has the sample user and password configured. The user must also have the roles "role1" and "tomcat" (this is the way the tomcat demo works - nothing to do with OpenIG...)
  • Before using the gateway make sure you can login directly to the sample application without going through the gateway (for this example: try logging in to http://openam.example.com:48080/examples/jsp/security/protected/)
  • OpenIG is running on another tomcat instance on port 28080 
  • You have followed the OpenIG guide to integrate OpenAM and OpenIG, and enable the password capture post auth handler. 

You now should be able to go to 

http://openam.example.com:28080/examples/jsp/security/protected/login.jsp 

If all is well you will be redirected to OpenAM. Once you have authenticated, the gateway will inject your credentials into the flow and log you in to the sample application.