Best Practice for IAM Projects

I was recently asked to provide some best practice advice for Identity Management projects. This got me thinking and led me to write down some recommendations. I thought it might be useful to share my thoughts.

Identity Management has been delivering business value within organisations for many years. Over that time, thousands of deployment had enabled a number of lessons to be learned which can help organisations ensure that they are not taking an approach which will work against recognised good practice and cause problems as Identity requirements evolve.

Traditionally, Identity Management projects have been seen as complex, expensive and never-ending. Many people are looking to the Cloud to simplify identity management. Whilst the Cloud can introduce speed and agility into an IAM project, there are still fundamental challenges which must be addressed. The Cloud can help simplify the technology, however, as with most business transformation projects; the technology is only one part in the triad of People, Process, and Technology.

It has been seen, over and over again, that many organisations fall into the same pitfalls with IAM projects. Here are some of the areas which organisations must consider when looking at an IAM project.

Business-Driven Project – In my experience, the biggest cause of failure is when an IAM project is treated purely as an IT project. Implementing IAM has a significant impact on the business and organisational and cultural impact cannot be underestimated. At the end of the day, you are not just trying to automate existing processes, you are using the IAM project to re-evaluate business processes to make them more efficient. Early engagement with the business is crucial to the success of an IAM project, which should be seen as an enabler for business strategy, i.e. providing a foundation to open up the business on new channels (digital transformation).

Minimise Customisation – Most organisations think of themselves as unique, having individual requirements which no other organisation has. Therefore, Identity Management solutions are often heavily customised to meet existing business processes and procedures. This makes any IAM platform expensive to manage and difficult to upgrade and maintain. In reality, irrespective of industry, most organisations have very similar IAM requirements and therefore, most processes (e.g. a joiner’s process) can, and should be standardised. Offering lines of business the ultimate level of flexibility and configuration comes at a high price. Of course, there may be that one edge case which absolutely needs customisation and therefore, any IAM solution must be flexible enough to support this. However, addressing the bulk set of use cases should be as standardised as possible. Instead of approaching requirements like “What do you want the flow to be?”, you should approach it like, “Is there any reason why I can’t use this standard flow?” Whilst the Oracle IAM platform enables a high level of flexibility if it is necessary, it also provides a number of out-of-the-box configuration options to help minimise the level of customisation required. This includes (but is not limited to): A number of standard approval workflows, UIs which can be branded and configured without customisation, and a rich set of APIs where extended capability is required, but avoiding customisation of the core platform and making upgrades difficult.

Utilise Open Standards – Proprietary or bespoke integrations add another layer of complexity and cost to any deployment. Identity open standards are mature and provide a rich set of protocols, including: SAML, OAuth, OpenID Connect, SCIM, and LDAP. Where possible, open standards should be used to avoid the need to develop and maintain bespoke integrations. Oracle is a firm believer in open standards. Not only are identity open standards widely supported across our platform, but Oracle also helps to drive many of the above open standards through direct involvement in the appropriate working groups.

Consider All Identity Types – Whilst an organisation may be considering Identity Management for a specific project today, requirements evolve. Digital transformation has shown that customer focus has become more important than ever before. It is important that an organisation’s Identity Management platform is capable of handling, yet unknown Identity Management requirements, across multiple channels, for different sets of users, covering a myriad of use cases. Recognising that different use cases may require different approaches is also critical. For example, enabling digital services for a new set of customers, where all of the underpinning applications exist in the cloud may mean that those users only exist as a cloud identity. However, enabling partner access where access to systems exists across both on-premise and cloud may mean the users need to exist across both environments. It is important that organisations consider an IAM platform which has the capabilities to accommodate all such use cases as well as the correct architectural approach to delivery new requirements in the future. Oracle’s hybrid IAM platform enables this flexibility underpinned by a strong architecture.

Platform vs Point Solutions – As mentioned at the outset, Identity Management is typically seen as a long, complex, expensive project to deploy across an enterprise. There are a number of factors which affect this. However, one of the biggest costs is integration, whether between IAM products or integrating the IAM solution with external components such as target applications. Trying to plumb together Identity Management products from multiple different vendors provides unnecessary costs and complexity and will drive up delivery costs. Industry analysis[1] has shown that deploying a platform which already has the integration work completed can provide cost savings of up to 48%, leading to 35% fewer deficiencies. Adopting a platform does not mean sacrificing functionality. It is possible to get best of breed capabilities whilst still benefiting from a platform. The Oracle IAM platform is regularly recognised as a market leading in individual pillars[2].

Small, incremental wins – In today’s world of rapid agile development, no-one wants to see long running projects which deliver very little value or return until near the end. Identity Management is no different. Therefore, it is crucial that quick wins are delivered and that ongoing wins are incrementally delivered throughout the lifecycle of the project. For example, if you are doing user lifecycle management, get to grips with the process for requesting access first. Then you can start to integrate your targets, again, all in phased approaches. For access management, integrate the apps with the biggest impact on the end user experience first. Don’t focus on the app which is only used by 10 people in a single department.

Information Governance – An IAM project should align to an organisation’s information governance strategy in order to be deemed a success. This includes factors such as regulatory compliance, business continuity planning, operational security (e.g. key management, vulnerability scanning etc.) and should consider integration with such dependent IT systems when delivering any IAM project.

Many of the above points may seem like common sense and the logical approach. Indeed, I am seeing a shift within customers as some of these points are being now being actively rolled into projects and business requirements. However, I am also still seeing the older approach. Hopefully, this post has been useful in providing some pointers for your next IAM project.


[1] Aberdeen Group “Analysing Point Solutions vs Platforms”

[2] Gartner Magic Quadrant for Identity Governance and Administration 2016

Integrating Oracle Access Management platform with Mobile Application Framework

The shift from desktop and laptop to mobile working is well underway. Many organisations today have either written one (or more) mobile applications for their customers/employees, or are considering it. They understand the importance that mobile computing is having and its growing dominance in the next few years as the primary platform for many users. However, as the use of the platform grows so do users’ expectations. They want an immersive, engaging experience, not just a mobile-friendly rendering of a website. If you don’t capture that ‘wow factor’ within the first few minutes, your app will be deleted.

From a security perspective, this causes IT a challenge. Now you have sensitive information being delivered outside of your network and stored on a potentially unsecured device. On top of that we now have the added complexity of an additional channel to deal with. To make matters worse, customers have come to expect security to deliver them an enhanced user experience, not just control their access to information. For example, user take web-based SSO for granted. You don’t expect to have to enter your credentials more than once when you access a company’s website. Typically, users don’t differentiate between a web and mobile channel and therefore expect the same level of user experience. This can be a challenge for an organisation to deliver. How do you re-use that existing Identity and Access Management platform that you have deployed for your web channel and extend it out to your mobile channel, thus gaining re-use whilst saving time and costs.

Fortunately, Oracle makes it extremely easy to do through our Mobile Application Framework. Now, you can take your existing Oracle Identity and Access Management platform and use it as the security layer within your mobile applications. You can use the full capabilities of the platform including risk-based authentication, social identity authentication, as well as authorisation. What’s even better is that you can achieve all of this without writing a single line of code. Yes, that’s right, no coding required.

Let me show you how.

First let’s take a look at my sample application. It won’t win any awards for design, but as you can see it’s made up of 3 separate features (N.B. a feature is a capability).

At the moment, there is no security enabled within the app so you can move back and forth between the features without any authentication.

Now we are going to add two different types of authentication to our application. Yes, as you guessed, the first is a risk-based authentication and the second is social login. Within my environment, I am using JDev 12c (12.1.3) and have Oracle Access Management installed and configured to protect web-based content. Therefore, the user directory and underlying connections are already configured. I have also enabled its Mobile and Social capability.

1. Oracle Access Management Mobile and Social Configuration

When you first enable Mobile and Social, most of the configuration is already setup for you by default. In addition to the out-of-the-box configuration, I created an Application Profile for my MAF application.

The key settings here are to configure it as a “Mobile Configuration” and to provide the platform specific settings. I then configure the MobileServiceDomain.

In this screen I need to configure the security handler and then link my Application Profile to the service domain. Since we want risk-based authentication, then we select the pre-defined “OaamSecurityHandlerPlugin”. After adding our MAFTest application profile to this domain we can save the changes.

That’s all we need to configure on the server side for now, so we can focus on our MAF application.

2. MAF Sample Application Configuration

Within my application I can easily see the three features that I have defined. At the moment, none of them have security enabled. We will start by enabling security for the Risk-based login. This is done by checking the box under “Enable Security”.

We have told MAF that we want to secure that feature but not how we will authenticate. So, the next step is within MAF-application.xml where we define the connection for our security server. In our case we are configuring a connection to our OAM mobile and social service. We do this by adding a new MAF Login Connection.

As you can see we have used the Service Domain and Application Profiles that we created earlier. Also, I am using a HTTP load balancer between my application tier and external, so I am pointing my connection at port 80. If you were connecting directly to OAM on the default port you would specify port 14100.

Now that I have defined the connection, I can associate that new MAF Login connection with the feature I have enabled security for.

Now, I can save all of my work and deploy my application.

This time when I try to access the risk-based login feature, I get a very different user experience.

Firstly, I am prompted for authentication. These are the same credentials that I would use for any other access (e.g. web-based access) since we are re-using the same access management platform. However, rather than just providing username and password authentication, as part of the login process the Oracle Access Management platform is undertaking a risk-based assessment of the attempted login. It is capturing a number of characteristics such as the device’s unique fingerprint and location information and comparing it to standard behaviour. In this case, it has decided that there is sufficient risk to require an additional level of authentication, which is does through sending me a one-time code. This could just as easily be configured to require me to answer a pre-registered challenge question. You can see a summary of the session within the risk engine web-based UI below.

This shows the a number of policies were executed, a risk score determined and an action of “Challenge” was decided. For organisations not using the risk-based capability of Oracle Access Management, we can provide standard, non risk-based authentication. All we need to do is change the security plugin within the Access Management to use the standard plugin.

So, in summary, what we have just seen is that through configuration alone we have provided security to our sample MAF application using our existing Access Management platform and without writing a single line of code, all through point and click configuration.

Now, let’s extend our use case slightly. We have provided risk-based authentication but what about a lower level of authentication. Many organisations are taking advantage of social authentication to onboard user’s easier and lower the barrier of entry to user’s to access personalised content. It also gives organisations access to a range of social information about the user they wouldn’t previously have had access to. Of course, most social networks expose the APIs to provide this. However, despite using open standards such as OAUTH and OpenID, the integration with each social network is slightly different in its use and configuration. We have extended Oracle’s Access Management platform to take away the headache of trying to integrate with each individual social provider and instead made it a configuration exercise. Yes, you guessed it, without any coding for the developer of your mobile application. Let’s have a look at the configuration.

3. Social Identity Server Side Configuration

The first step is configure each of our providers that we want to use. Whilst most social identity providers offer their services for free, you have to register and obtain the necessary API tokens to call their service. Within the Access Management console we define the connection specific settings, such as those shown below for Facebook.

Instructions are provided in the product documentation around how to obtain the consumer key and secret needed. As you can see, we also define which attributes we want the social provider to return. At the time of writing this, the Oracle Access Management platform provider out-of-the-box integration with Facebook, Twitter, LinkedIn, Google, and Yahoo. You can create your own custom providers if you have requirements beyond these.

Once we have configured the providers, we define an Application Profile covering social identity login.

This application profile includes details of which social providers we want to enable and how we map the attributes returned from each provider to local attributes in the user repository. In our example, we will just configure Facebook first.

We then create a new Service Domain to link our Application Profile to social login.

Again, that is all we need to configure on the server side. Now to focus on the client.

2. MAF configuration for social identity integration

As before, the first step is to tell MAF that we want to secure our second feature.

We then have to create a new MAF Login Connection for our social integration.

Just as before we create a new connection and configure it to point to the configurations we defined above. Once we have created the connection, we map it to the feature that we want to apply it to, in our case, mycomp.Help2.

That’s it for configuration. Now we can deploy and test our application. This time, after deploying we see a very different flow.

The user is shown their available social providers and they pick one. They are then taken to that provider to authenticate and provider consent (if they haven’t done previously) before being returned to the sample app as an authenticated user.

What’s really nice about this approach is that if I want to change providers, I can make the change server side and it immediately takes effect. So, if I wanted to add Google as a second provider, I make the change in the Oracle Access Management console to add Google to my Application Profile.

When I apply the change, the next time I try to login to my MAF application through social integration I see that change.

Of course, all of the login screens etc that you have seen can be customised. I am using the default, out-of-the-box screens for simplicity.

In summary, what you have seen in the last section is how I can configure a MAF application to support authentication through a range of social identity providers, again without writing a single line of code.

There is also a great video from a colleague that explains each component in a bit more detail.

I hope you found this useful.


Most Important Security Lesson

During a job interview several years ago, I was asked a question that has stuck with me ever since. The question was along the lines of:

“If you could offer one piece of security advice to your customer, what would it be?”

At the time, my immediate answer was “Education, education, education. Teach your employees about security as they are the weakest link in the chain.” Over the years since that interview (disclosure: I got the job), I have often thought whether I could have provided a better answer. In fact, when I interview candidates for jobs today I often ask them that same question to see what their response it. I receive a variety of answers, usually technical.

So far, I haven’t come up with a better answer. Sure, we need to enforce perimeter security as well as standard security best practice, such as “Least Privilege” etc, but I can’t think of a single more important security lesson that my lesson above. You can have a very mature Information Security Management System will all the right controls in place but if you have a compromised user, or even worse a compromised, privileged user, then many of those controls are ineffective.

It is commonly recognised that security controls are a combination of people, processes, and technology. I think, too often we pay too little attention to the people aspect. Security controls have to be looked at holistically, taking into account all three of these facets. That will ensure that you can minimise the potential loss when you are hacked.

Yes, I use the term “when” as opposed to “if”. Every day almost, we see reports of data breaches, many from companies with good security controls in-place. Therefore, I believe it is naive to think that your organisation is un-hackable. That is why it is so important to make sure you have the right security controls and training in place, before this happens, not after.

Protecting Children Online

Over the last two days I have had the privilege of participating in a summit of industry experts to look at innovative ways that technology can help prevent online sexual abuse of children. The event, organised by WeProtect, brought together over 80 individuals from around 40 companies to look at the threats and how they can be addressed.

It was great to see so many competitor organisations putting their differences to one side, leaving their company affiliations (and egos) at the door and instead working together, as individuals to come up with solutions to these very real threats to our children, not just in the UK, but globally. There were some fantastic and inspiring ideas generated that I hope we can build on and, as an industry, start to deliver over the coming months.

Of course, as expected some of these solutions are not overnight fixes and there is no silver bullet to solve this problem (or it would have been done already). However, there were some very pragmatic, tactical solutions that are eminently achievable without hvaing to move mountains.

It was a real honour to work with my industry colleagues at this event on such a difficult and emotive subject that everyone at the event was so passionate about. It’s time like this when I am really proud of the work that the collaboration of great minds can produce.

UK Govt – No preventative security measures for internal users. Are they mad??

Reading the Government Service Design Manual and especially the section on Security as an Enabler, I found an interesting paragraph in there, when talking about internal users, it states:

“It is the intention of the Civil Service Reform Plan and the new Security Classification Policy that there is greater emphasis on user responsibility, reducing expensive and overbearing technical controls. This requires proper training to assist users in handling sensitive information, and auditing to verify users are acting responsibly.

Users should be trusted to carry out their roles and given the responsibility to do so securely.

Audit and verification of user behaviour should be used to ensure policy compliance instead of preventative measures which add cost and degrade productivity. Such audit and verification should be implemented by services or network infrastructure, away from the end user device.”

I find this a shocking statement. You only have to look at the press or read the annual Verizon Data Breach report to show that the threat from insiders is growing (14% in 2013) with 13% of breaches occurring from privilege misuse or abuse.

It’s very brave (or stupid) to rely on detective controls and therefore close the stable door, only once the horse has bolted. Surely the cost and ‘degraded productivity’ should be measured against the increased risk and reduced compliance.

I would argue that to use security as an enabler, you must ensure that you do have the appropriate mix of preventative AND detective controls in place before you can enable those services that are going to provide the real benefits and savings.

Authorisation comes full circle

I find it really interesting to look at access control of web-based applications to see how they have changed over the past decade.

When I first started working with Identity and Access management back in 1998/1999, web applications were still emerging and there functionality was limited. At that time people were building silo’d applications containing all of the security within each application. Then along came the web access management (WAM) vendors including Netegrity, Oblix etc. All of these vendors took a new approach to web application security. Their approach was to remove the security out of the application and instead, put it into a security framework which surrounded your applications. This became a common access point which provided a range of features including:

  • Web-based SSO
  • Authentication
  • Authorisation
  • Auditing

This was all well and good but as applications developed and became increasingly complex, it became harder to meet all of the applications’ security requirements through this framework. Sure, authentication was straight-forward. Lets authenticate the user and then pass a token to the application containing the user’s identity. This has been done over and over again and is now a very well-trodden path.

However, what about authorisation? This wasn’t so simple. Despite their claims of handling authorisation, the WAM products primarily worked on URL. They were able to carve up the URL into chunks and decide which user’s got access to which chunks. This was fine in some cases, but more often than not, was not enough for many applications.

As applications matured, there were more requirements to do complex authorisation based on defining access control at levels deeper than the URL. The WAM vendors answer typically was to pass some information from the user directory to the application and let the application perform that level of authorisation. I have deployed many WAM solutions during my consulting days. The majority of those used WAM to provide authentication but left the authorisation to the underlying applications. So, we ended up with a half-way house. WAM providing authentication and some high-level authorisation, with applications providing the more detailed authorisation. Not ideal!

Then as the market has matured even more, we see the advent of products like Oracle Entitlements Server which addresses this problem. How do we provide a solution which allows us to not only externalise authentication and the high-level (coarse-grained) authorisation but also the low-level (fine-grained) authorisation? We now have the answer to providing a complete solution in this area.

We can now use WAM to provide the authentication and coarse-grained authorisation whilst allowing an entitlements service to provide the fine-grained authorisation.

Surely, this is where the WAM vendors first imagined we would be, i.e. externalising all of the access control from the web application. It just seems that it has taken us a bit longer than expected to get there.