ForgeRock Open Identity Summit comes to Europe…

Join us for the Open Identity Stack Summit Europe, on 14-16 October 2013 at the Domaine de Béhoust, France.

We will be gathering at ForgeRock’s luxe Chateau, Domaine de Béhoust (just outside Paris), where our Open Identity Stack community will delve into OpenAM, OpenIDM, and OpenDJ best practices, use cases, how-tos, and more.

We’ve been saying for a long time that identity & access management (IAM) must be reconstructed to adapt to today’s problems. Modern APIs, standards, scale, speed, and modular architecture are all needed for successful modern IAM deployments. The agenda will include dynamic working sessions addressing the latest IAM developments, including mobility, identity bridge, and customer case studies.

A call for papers is open. If you are doing something interesting with the Open Identity Stack and you would like to share the experience by presenting a session at the summit, send your proposal by September 4.

ForgeRock’s chateau is large, but registration is limited. Therefore, I encourage you to reserve your spot and register quickly !

If you want to get a feel of the atmosphere of the conference, check the photo album from the first ForgeRock Open Identity Summit or get a glimpse at the skills of one of our keynote speakers :
LP0_8856I hope to see you at ForgeRock’s chateau in October !

 


Filed under: General Tagged: conference, europe, ForgeRock, france, identity, openam, opendj, OpenIdentityStack, openidm, opensource, summit

Java EE agent internals

Not so long ago I’ve been working on JBoss v7 agent, so let me try to sum up some of my findings with Java EE agents in general.
A Java EE agent basically stands from 4 main components:

  • Installer
  • Container specific JAAS integration
  • Java EE Filter implementation
  • Agent application

Let’s go through each one of these and see how they really work.

Agent installer

As its name suggest, the agent installer helps to install the Policy Agent (PA) on the chosen Java EE container. The main behavior of the installer is defined within config/configure.xml file. This file is basically a big XML descriptor of the followings:

  • interactions – what should be asked from the user when performing install/custom-install/migrate/uninstall
  • tasks – what tasks needs to be performed as part of the agent installation, things like backup, creating directory layout, etc

So basically this XML describes how the installer should work in general. Now let’s go even more deeper…

Interactions

During an agent installation all user input is being stored in a thing called IStateAccess (well sometimes there is a persistent=”false” interaction which isn’t persistent, but that part I don’t fully grasp yet :) ).
As part of an interaction it is possible to set up different validators (even custom ones), so for example this makes it possible that a given agent is actually installed on a supported container version. For example with JBoss we are running “JBOSS_HOME/bin/instancename.(bat|sh) –version” command to get back the version number of the JBoss instance, parse it and if it matches, we let the installer further.

Tasks

Tasks are usually just a well defined “change” that needs to be performed by the installer. Implementing a task is not just performing a given change, rollback is just as important part of it. In order to make an agent work, it is very likely that some container specific configuration file needs to be modified (for example to configure/enable the JAAS integration), the necessary file paths are all calculated based on the user input during the interactions (IStateAccess).
Usually an agent installer performs the following tasks:

  • creating backups for the container’s configuration files
  • perform modifications to the container configuration
  • create agent directory layout (i.e. creating the Agent_00x folder structure)
  • encrypt the agent profile’s password and save it in the agent bootstrap config
  • generate the configuration files based on the values provided to the installer
  • in certain scenarios: deploy agentapp.war in the container
  • in case of custom-install: create agent profile if needed

As you can probably see there is nothing super magical about the agent installer, its sole purpose is basically to make the deployer’s life easier by automating this whole process.
I feel we heard enough about the installer for now, so let’s go a bit further and see what the JAAS integration is really all about.

Container specific JAAS integration

JAAS in general isn’t that new really, it’s been part of JRE 1.4 already, so let’s look at it very shortly (here is a longer version):

  • You can implement a custom authentication module
  • You can define authentication “chains” using built-in/custom modules in a configuration file

Well hopefully this concept doesn’t sound too new for you, since the whole OpenAM authentication system is based on JAAS. ;)
As an extra, application servers tend to have the concept of “JAAS realm”, which is basically a collection of users (to be sparse as much as possible). Unfortunately there is not much standard around implementing JAAS support for application servers, so this part of the agents is different per container (and sometimes even across container versions).

Advantages of JAAS

Well the main advantage of JAAS is that it can help making the OpenAM integration as less intrusive as possible, but there are others as well:

  • Retrieving the logged in user’s name is quite simple, you can call request#getRemoteUser() or request#getUserPrincipal().
  • By setting up Java EE Security it is possible to define roles in the application’s descriptor files and later on in your application you can just simply check against these using request#isUserInRole(String) (authorization).
  • In case you later on decide to use an LDAP based JAAS module instead, the idea is that you can simply switch out the JAAS login module (of course you’ll need to configure it to work similarly to OpenAM), without actually modifying any part of your application code.
  • While this is already good enough, I think JAAS really pays off when EJBs are used in applications. In that case you can use the @DeclareRoles and @RolesAllowed annotations and magically your EJB method will be protected, only those in the configured role can actually invoke the method (anything else results in failure), which sounds quite neat. :)

So what about agents?

The Java EE agents support JAAS, they integrate well with the container and within the agent configuration it is possible to set up role mapping based on pretty much any arbitrary data (session property, profile attribute). To enable JAAS support though you must ensure that you configure the agent in J2EE_POLICY or ALL mode. While it is possible to define security-constraints in web.xml to protect access to pages, usually that’s a bit cumbersome, instead it’s probably simpler to just define OpenAM policies (i.e. use the agent in ALL mode), and only use JAAS for the previously described goodies.

Java EE Filter implementation

The agent itself is implemented as a Java EE filter, which is (obviously) standard, so this part is common for all the agents and as such it is part of the agent SDK. When the filter intercepts a given request, it will basically go through a list of “TaskHandlers” and execute them in a predefined order. If a given TaskHandler returns with an AmFilterResult, then the processing stops and the result will be handled. Here is a small example subset of the available TaskHandlers:

  • CDSSOTaskHandler – detects if the user needs to authenticate using CDSSO and redirects to CDCServlet if necessary
  • CDSSOResultTaskHandler – processes the incoming LARES response and creates the cookie on the application’s domain
  • URLPolicyTaskHandler – checks the currently visited URL against configured URL policies in OpenAM, and blocks access if necessary
  • InitialPDPTaskHandler – saves POST data if the user hasn’t authenticated yet, so later on the POST can be resubmitted once authentication took place.
  • XSSDetectionTaskHandler – checks incoming request parameters for malicious characters

Since the agent is implemented as a filter, you can see how it can alter the outcome of a given incoming request. If the user doesn’t have session yet, it will prevent further processing of the page, and redirect straight to OpenAM instead. This however means that in order to protect the application fully, you must set the agent’s filter as the first one, otherwise it may be possible that a filter earlier in the chain alters the response, or returns earlier, which could basically prevent the agent to protect the application properly.

Agent application

And here is the last component which is pretty simple, the agent application. The purpose of this application is to provide a unique contextroot for the agent, so the agent can receive notifications from OpenAM, and also LARES responses in case of CDSSO. To be fair the agentapp only has the agent’s filter defined, and that basically handles everything. If there is an incoming notification, then the filter just checks if the requested URL is actually the notification URL, and processes it if so.
As a sidenote I would mention that deploying agentapp.war is not necessary when using global web.xml with Tomcat 6. That is simply because the global web filter already includes the agent filter, hence any incoming request to the /agentapp context will be catched by the filter already.

Conclusion

Agents are fun, but that doesn’t mean they are not complex. :)

2-Factor Is Great, But Passwords Still Weak Spot

The last few months have seen a plethora of consumer focused websites and services, all adding in two-factor authentication systems, in order to improve security.  The main focus of these additional authentication steps, generally involve a secondary one time password, being sent to the authenticating user, either via a previously registered email address or mobile phone number.  This is moving the authentication process away from something the user knows (username and password) to something the user has - either an email address or mobile phone.  Whilst these additional processes certainly go some way to improve security, and reduce the significance of the account password, it highlights a few interesting issues, mainly that password based authentication is still a weak link.




Consumers Accept New Security

Two factor authentication solutions have been around for a number of years, either in the form of hard tokens (RSA for example) or physical proximity cards for use with a pin to access a controlled physical site.  However, many have been used for general high security enterprise or internal scenarios, such as access to data centers or perhaps dialing into a secure network from an unsecure location.  The interesting aspect today, is that many of these SMS based 'soft' approaches to two factor authentication, are being made available to consumers, accessing standard web applications and sites.  The services those sites offer, whilst containing identity data or personal information, are not particularly life threatening or business critical.  It is interesting to see websites taking a risk with regards to user convenience, in order to implement greater security.  As a security professional, even just from an awareness perspective this a positive move.  Many end users, most of whom are non-technical, now willingly accept these additional steps, in order to reduce the risk associated with their account being hacked.


Password Security is Fundamentally Weak

But why the increased use of two-factor and why are users happy to accept this new level of security?  The main underlying point, is that simple password based authentication, is and never really will be, a totally secure way of protecting resources.  I've blogged on this topic several times in the past 18 months (Passwords And Why They're Going Nowhere, - March 2013,  The Problem With Passwords (again, still) - Oct 2012, The Password Is Dead (long live the password!) - Feb 2012), but the situation still remains: passwords have numerous weaknesses.  Some arise from the end user side (use of non-complex passwords, password sharing between sites, passwords being written down) and some from the custodian side, especially with regards to password storage (use of clear text - yes really!, symmetric encryption as opposed to hashing) and password transit (use of non SSL / HTTPS communication).  The complexity of password hacking techniques is also pretty mature, with automated tooling, pre-compiled hashing tables and harvesting engines, all make application protected by just a username and password, a risky proposition.

Biometrics - Face Recognition

Ok, so everyone knows passwords are weak.  So what are the options?  Due to the rise of mobile technology - both smart phones and tablets - the raw hardware technology available to most end users, is considerably higher than it was say 5 years ago.  Most devices will have high resolution cameras and touch screens that can be used for additional authentication checks, without the need for additional costly hardware.  Facial recognition is available on many of the Android and iOS handsets, when used alongside a secondary PIN.  Most facial recognition systems either use an algorithm to analyze the relative position of things like the nose, eyes and mouth or perhaps analyse a selection of facial images to create a normalized view.  This area is certainly developing, but can perhaps be circumvented by pictorial replays or other savvy attacks.  Google has certainly taken a lead in this area, by recently announcing a patent based on facial authentication.


Biometrics - Voice Recognition

Another area of interest is that of voice or speech based authentication.  On a similar front to facial recognition, this is focusing on the premise, that something you are, is certainly a lot more secure than something you know (password) and even more so than something you own (token).  Vocal recognition requires the 'printing' of the users voice, in order to identify the unique characteristics of the individual.  This is akin to a fingerprint, and when measured accurately using the amplification levels of key frequencies and other pause factors, makes an arguably world unique view of a user's voice, similar to a DNA sample.  At login time, a user is asked to repeat a certain phrase that was used at registration time in order to identify a match.

Any biometric method will raise questions about practicality (accuracy of technology, avoidance of poor type I and type II error rates for example), as well as managing the privacy concerns of holding individual biological data.  The latter part however, could probably be overcome by holding simple hashes of key checking metrics as opposed to raw data.

Either way, passwords may at last be on the long goodbye away from centre stage.

By Simon Moffatt

2-Factor Is Great, But Passwords Still Weak Spot

The last few months have seen a plethora of consumer focused websites and services, all adding in two-factor authentication systems, in order to improve security.  The main focus of these additional authentication steps, generally involve a secondary one time password, being sent to the authenticating user, either via a previously registered email address or mobile phone number.  This is moving the authentication process away from something the user knows (username and password) to something the user has - either an email address or mobile phone.  Whilst these additional processes certainly go some way to improve security, and reduce the significance of the account password, it highlights a few interesting issues, mainly that password based authentication is still a weak link.




Consumers Accept New Security

Two factor authentication solutions have been around for a number of years, either in the form of hard tokens (RSA for example) or physical proximity cards for use with a pin to access a controlled physical site.  However, many have been used for general high security enterprise or internal scenarios, such as access to data centers or perhaps dialing into a secure network from an unsecure location.  The interesting aspect today, is that many of these SMS based 'soft' approaches to two factor authentication, are being made available to consumers, accessing standard web applications and sites.  The services those sites offer, whilst containing identity data or personal information, are not particularly life threatening or business critical.  It is interesting to see websites taking a risk with regards to user convenience, in order to implement greater security.  As a security professional, even just from an awareness perspective this a positive move.  Many end users, most of whom are non-technical, now willingly accept these additional steps, in order to reduce the risk associated with their account being hacked.


Password Security is Fundamentally Weak

But why the increased use of two-factor and why are users happy to accept this new level of security?  The main underlying point, is that simple password based authentication, is and never really will be, a totally secure way of protecting resources.  I've blogged on this topic several times in the past 18 months (Passwords And Why They're Going Nowhere, - March 2013,  The Problem With Passwords (again, still) - Oct 2012, The Password Is Dead (long live the password!) - Feb 2012), but the situation still remains: passwords have numerous weaknesses.  Some arise from the end user side (use of non-complex passwords, password sharing between sites, passwords being written down) and some from the custodian side, especially with regards to password storage (use of clear text - yes really!, symmetric encryption as opposed to hashing) and password transit (use of non SSL / HTTPS communication).  The complexity of password hacking techniques is also pretty mature, with automated tooling, pre-compiled hashing tables and harvesting engines, all make application protected by just a username and password, a risky proposition.

Biometrics - Face Recognition

Ok, so everyone knows passwords are weak.  So what are the options?  Due to the rise of mobile technology - both smart phones and tablets - the raw hardware technology available to most end users, is considerably higher than it was say 5 years ago.  Most devices will have high resolution cameras and touch screens that can be used for additional authentication checks, without the need for additional costly hardware.  Facial recognition is available on many of the Android and iOS handsets, when used alongside a secondary PIN.  Most facial recognition systems either use an algorithm to analyze the relative position of things like the nose, eyes and mouth or perhaps analyse a selection of facial images to create a normalized view.  This area is certainly developing, but can perhaps be circumvented by pictorial replays or other savvy attacks.  Google has certainly taken a lead in this area, by recently announcing a patent based on facial authentication.


Biometrics - Voice Recognition

Another area of interest is that of voice or speech based authentication.  On a similar front to facial recognition, this is focusing on the premise, that something you are, is certainly a lot more secure than something you know (password) and even more so than something you own (token).  Vocal recognition requires the 'printing' of the users voice, in order to identify the unique characteristics of the individual.  This is akin to a fingerprint, and when measured accurately using the amplification levels of key frequencies and other pause factors, makes an arguably world unique view of a user's voice, similar to a DNA sample.  At login time, a user is asked to repeat a certain phrase that was used at registration time in order to identify a match.

Any biometric method will raise questions about practicality (accuracy of technology, avoidance of poor type I and type II error rates for example), as well as managing the privacy concerns of holding individual biological data.  The latter part however, could probably be overcome by holding simple hashes of key checking metrics as opposed to raw data.

Either way, passwords may at last be on the long goodbye away from centre stage.

By Simon Moffatt

OpenDJ 2.6.0 is now available

OpenDJ-300x100I am really happy to announce the general availability of OpenDJ 2.6.0, a major update of ForgeRock  directory service product, built from the tag 2.6.0 (revision 9086 in our SVN repository).

OpenDJ 2.6.0 brings a lot of added value, including :

- A REST to LDAP service, allowing an easy access to directory data using HTTP/JSON. The service can be run either embedded in the server or as a standalone web application.

- A new upgrade process to ease transition from OpenDJ 2.4.5 or newer to 2.6.

- New Linux native packages (RPM and Debian) to facilitate the automatic deployment of OpenDJ in the private and public cloud.

- OpenDJ can be configured to delegate authentication to a Microsoft Active Directory service, providing tighter integration with Microsoft environment without the burden of synchronizing passwords.

- An optional extension to remove specific attributes from updates, making it more flexible and easier to deal with legacy applications and migration tasks.

- A way to synchronize SAMBA password attributes with the user’s password.

- Some improvements on the integrity of references, that is now enforced at creation or on update.

- More flexible and efficient audit logs.

- A Java based LDAP software development kit.

- An official stable documentation.

For the complete list of new features, enhancements and fixed defects, please read the release notes.

The binaries can be downloaded from ForgeRock Downloads.

Over the course of the development of OpenDJ, we’ve received many contributions, in form of code, issues raised in our JIRA, documentation… We address our deepest thanks to all the contributors and developers :

Aiman Tahboub, Alan Evans, Arturo V Sanchez, Auke Schrijnen, Bernhard Thalmayr, Brent Palmer, Bruno Vernay, Chris Dowey, Chris Ridd, Christophe Sovant, Dan Gardner, Danny Turner, Darin Perusich, Donal Duane, Elliot Kendall, Eswar Moorthy, Fred Voss, Gael Allioux, Gary Williams, German Parente, Göran Odmyr, Ian McGlothlin, Jamie Nelson, Jean-Noël Rouvignac, Jeff Blaine, Jeffrey Crawford, Jens Elkner, Lana Frost, Laurent Bristiel, Ludovic Poitou, Manuel Gaupp, Manuel Schallar, Mark Craig, Mark Gibson, Marko Harjula, Martin Sperle, Matthew Stevenson, Matthew Swift, Miroslav Fadrhonc, Mitch Silverstein, Nemanja Lukić, Nicholas Sushkin , Nikolay Belaevski, Per-Olov Sjoholm, Peter Major, Rauli Ikonen, Sachiko Wallace, Slavomir Katuscak, Tomas Forsman, Vanessa Richie, Violette Roche, Willi Burmeister

Happy 4th of July everyone !


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

sqlplus substr formating and column width


Doing a little connection pool troubleshooting (OAAM, I am looking at you!)  I found a great sqlplus script on stackoverflow.

The script uses the substr function to format the width of each column. As in:


select
       substr(a.spid,1,9) pid,
       substr(b.sid,1,5) sid,
       substr(b.serial#,1,5) ser#,
..

The problem: The column widths are all too wide. The values specified in the substr function seem to be ignored.

The solution:  If your database is using a multi-byte character encoding (and why wouldn't you?) you need to use the substrb function. Like this:

select
       substrb(a.spid,1,9) pid,
       substrb(b.sid,1,5) sid,
       substrb(b.serial#,1,5) ser#,
..

The Rise & Protection of the API Economy

Nearly every decent web site and application will have an application programming interface (API) of some sort.  This may simply be another interface into the applications most advanced administrative controls, controls which perhaps are used by only 5% of users and would clutter up even the most clearly designed user interfaces.  To make those controls open to end users, they have traditionally been exposed in a programmatic manner, that only deep technologists would look at or need to use.  In addition, those API's were probably only ever exposed to private internal networks, where their protection from a security perspective was probably less of a concern.




API's Today

As more organizations (and consumers of course) leverage applications and services online, there is an increasing percentage of web based API's.  A quick book search on Amazon produces over 200  results with regards to their design.  Undergraduate computer science courses will often have a module on basic web programming, with the simplest examples now choosing to build out an API instead of a full blown user interface driven application.  Many consumer focused applications and social networking sites such as Twitter, Google and Facebook, all lean heavily towards API level features.


Why They're Popular

For the likes of the consumer focused social networking platforms, API's provide a powerful tool to promote developer adoption.  Increased developer adoption for the likes of Facebook, increase the attractiveness of the service being offered, especially if more versions of Angry Birds or Candy Crush are being released.  API's in this framework, are all about certain features and ease of use. The premise is focused on being able to expand and extend the underlying platform as quickly and simply as possible, using a variety of client libraries and languages.

From a more business focused web application, API's are more focused on integration, interoperability and customization.  Integration with regards to owned business logic and process, interoperability with regards to underlying system and language differences and customization, perhaps relating to user experience.

Many web services in general could be argued to be solely API driven.  Sites like the Google owned VirusTotal, which provides a virus checking aggregation service, can be accessed using a user interface or API.  The same could be applied to Google itself

Why They Need Protecting

As web services and applications switch to becoming more engine like in nature, with limited or no user interface at all, the protection of the underlying API becomes more important.  The increased popularity of REST as architecture for web API development, provides not only an increased ease of use for developers, but also simpler touch points for the authentication and authorization of endpoint clients.  Knowing which clients are accessing your API is critical, as is being able to restrict their access to certain features or URL's.

Like with many security related aspects, externalising the authentication and authorization aspect away from core API feature management, allows developers to focus on core use cases and consumer and business value, without worrying about security.


By Simon Moffatt

The Rise & Protection of the API Economy

Nearly every decent web site and application will have an application programming interface (API) of some sort.  This may simply be another interface into the applications most advanced administrative controls, controls which perhaps are used by only 5% of users and would clutter up even the most clearly designed user interfaces.  To make those controls open to end users, they have traditionally been exposed in a programmatic manner, that only deep technologists would look at or need to use.  In addition, those API's were probably only ever exposed to private internal networks, where their protection from a security perspective was probably less of a concern.




API's Today

As more organizations (and consumers of course) leverage applications and services online, there is an increasing percentage of web based API's.  A quick book search on Amazon produces over 200  results with regards to their design.  Undergraduate computer science courses will often have a module on basic web programming, with the simplest examples now choosing to build out an API instead of a full blown user interface driven application.  Many consumer focused applications and social networking sites such as Twitter, Google and Facebook, all lean heavily towards API level features.


Why They're Popular

For the likes of the consumer focused social networking platforms, API's provide a powerful tool to promote developer adoption.  Increased developer adoption for the likes of Facebook, increase the attractiveness of the service being offered, especially if more versions of Angry Birds or Candy Crush are being released.  API's in this framework, are all about certain features and ease of use. The premise is focused on being able to expand and extend the underlying platform as quickly and simply as possible, using a variety of client libraries and languages.

From a more business focused web application, API's are more focused on integration, interoperability and customization.  Integration with regards to owned business logic and process, interoperability with regards to underlying system and language differences and customization, perhaps relating to user experience.

Many web services in general could be argued to be solely API driven.  Sites like the Google owned VirusTotal, which provides a virus checking aggregation service, can be accessed using a user interface or API.  The same could be applied to Google itself

Why They Need Protecting

As web services and applications switch to becoming more engine like in nature, with limited or no user interface at all, the protection of the underlying API becomes more important.  The increased popularity of REST as architecture for web API development, provides not only an increased ease of use for developers, but also simpler touch points for the authentication and authorization of endpoint clients.  Knowing which clients are accessing your API is critical, as is being able to restrict their access to certain features or URL's.

Like with many security related aspects, externalising the authentication and authorization aspect away from core API feature management, allows developers to focus on core use cases and consumer and business value, without worrying about security.


By Simon Moffatt

Identity & Access Management: Give Me a REST

Give me a REST (or two weeks stay in a villa in Portugal if you're asking...).  RESTful architectures have been the general buzz of websites for the last few years.  The simplicity, scalability and statelessness of this approach to client-server communications has been adopted by many of the top social sites such as Twitter and Facebook.  Why?  Well, in their specific cases, developer adoption is a huge priority.  Getting as many Twitter clients or Facebook apps released, increases the overall attractiveness of those services and in a world where website and service competition is as high as ever, that is a key position to sustain.


Why REST?

Cute picture of RESTing lion [1]
The evolution and move to REST is quite a clear one from a benefits and adoption perspective.  REST re-uses many of the standard HTTP protocol verbs such as GET, POST and DELETE,  when constructing URL's.  These verbs are well understood and well used, so there's no new syntactic sugar to swallow.  Each component of the service owners database is abstracted into neatly described resources that can be accessed using the appropriate URI.  Requests can then be made to return, say, a JSON or XML representation of the underlying database object.



The client, permission granted, can then in turn update or create a new object in the same way, by sending a new JSON object via a PUT or POST request.

What's This Got To Do With IAM?

Identity management has often been thought of as an enterprise or organizational problem, focussing on the the creation and management of company email, mainframe and ERP system accounts.  This process then brought all the complexity of business workflow definition, compliance, audit, system integration and so on.  Access management on the other hand, has often been focused on single-sign-on, basic authorization and web protection.  IAM today is a much more complex and far reaching beast.  

Organizations are reaching out into the cloud for services, API's and applications.  Service providers and applications are becoming identity providers in their own right, reaching back out to consumers and businesses alike.  For once, identity management is on the tip of the tongue of the most tech-avoiding consumers, concerned with privacy, their online-identities and how they can be managed and consumed.

A RESTful Future

These new approaches to identity and access management require rapid integration, developer adoption and engine-like API's that can perform in an agile, scalable and secure fashion.  Identity and access management services for consumers, such as being able to login with their Facebook or Twitter account using OAuth or OAuth2 without having to create and manage multiple passwords for the other sites they interact with, not only increases user convenience.  It also puts pressure on business security strategies as they can struggle to cope with the ability for employees to bring-their-own-identity to many of the now popular business services such as Webex, Dropbox, Salesforce and the like.

As identity management is no longer solely concerned with siloed, business unit or organisational boundaries and looking more to being fully connected, integrated and focused on consumerization, developer adoption has never been more important.  Security in general, has never been a high priority for application builders, who are more centred on features and end usability.

Identity and access management is making a big change to that area with many access management systems being easy to externalize from application logic using RESTful integration.


By Simon Moffatt

[1] - Image attribute Stock.Xchng http://www.sxc.hu/profile.big_foot

Thanks to all participants of the 1st ForgeRock Open Identity Summit !

ForgeRock Open Identity Summit opening

I hope all attendees enjoyed the summit as much as I have. It’s been a real pleasure to meet face to face some of the project members, customers and partners I’ve interacted with, over emails and phone for the last 3 years, and to see again colleagues, ex-coworkers…

All the photos that I’ve captured during the summit are now publicly available on Flickr.

See you at the next summit !

[Update on June 19] The presentations from the summit are now online. Goto the Summit page and click on the Agenda.

LP0_8918LP0_8901LP0_8817


Filed under: General Tagged: conference, ForgeRock, identity, ois13, openam, opendj, openidm, photography, photos