Top 5 Security Predictions for 2015

January can't go by without another set of prediction blogs coming our way. Be that for lifestyle, how to lose weight, how to gain weight, how to change our lives and so on.  I thought I would join the band wagon and jot down what I think will be the top 5 challenges facing organisations from a security perspective this year.  If I'm being diligent enough, I may even review it come December (only if I'm right of course...).

Customer Identity Management Will Keep CIO's Awake at Night

Many organisations are going through digital transformation processes.  Be that public sector departments wanting to streamline areas such as taxation, driving license management or health care, through to private sector organisations looking to reduce costs or open new market opportunities.

Digital initiatives are everywhere.  Don't believe me? Check out how many CDO (Chief Digital Officers) now exist on LinkedIn - over 3000 in the UK alone.  These new approaches to product and service delivery, require a strong hold on the identity and access management requirements of customers.  Customer registration, authentication, two-factor authentication and device finger printing, are just a few of the topics hitting the to do list of many CISO's and CIO's - all services that suddenly need rolling out to potentially millions of end users.  Big scale and big headaches will result, if a modular and scalable identity platform isn't available.

Water Cooler Chat Will Be All About Device Security and Internet of Things Madness

By now, everyone has an automated toilet, with a mood influenced flush, that instantly publishes the meta data to Twitter right?  Perhaps not, but there is no doubting, that the Internet of Things landscape is maturing rapidly and the identity of things (shameless blog plug) is going to be a huge area for device manufacturers, services providers and end users.

IoT systems and devices, have all been about communications and interoperability so far.  Adding communications services to low power and low capacity devices brings new opportunities for things like home automation, smart cities, smart cars and more.  However, as these devices collect, store and distribute data to brokers and cloud services, data privacy becomes a huge concern, especially if the data contains production plant statistics or personal health information.  The devices, and the ecosystem that supports the delivery of those devices, will need to be coated in a meta layer of security, from registration and authentication services, through to lightweight encryption and signing technology.

Passwords on the Mobile Will Disappear (Ok not entirely..)

Passwords are dead. Long live the passwords.  I think this topic has been the most written about in blog history.  Ever.  Ok, perhaps not quite ever, but the number of column inches dedicated to the next big thing in password-less authentication / how passwords can't die / how passwords will die is quite remarkable.  One thing for sure, is that the number of users accessing web content and apps via mobile devices (be that phones or tablets) is continuing to rise and outstrip the need for desktops significantly.  What that does of course, is increase the desire for less reliance on password based authentication on mobile tech.  It's simply too inconvenient and too insecure.  As mobile devices build out easier to use secure elements, the storage of crypto materials, session tokens, refresh tokens and other authentication data, will allow for the proliferation of protocols such as OAuth2 or crypto related authentication schemes, to take precedence over the traditional username and password approach.

Employees Will Want Access to More Cloud Services

Many organisations are at a cross roads when it comes to cloud services.  Many want to embrace new, as-a-service based components such as HR, payroll, collaboration and office automation systems.  They are often very simple to register and pay for, simple to set up and allow the organisation to concentrate on their key competency areas.  This does however, bring strong challenges with regards to employee provisioning and single sign on to external services.  Employees do not want to have to remember new and different usernames and passwords to access Google Apps, Salesforce or HR Factors.  Single sign on is mandatory for user convenience, as is the ability to create and remove users in a streamlined and automated fashion, using provisioning systems deeply integrated to HR rules and business logic.  These new requirements can put strain on already buckling legacy provisioning and access management systems, that were often conceived and implemented long before the 'cloud' was cool.

Consumers Will Want More Control and Transparency Over Their Data

This last one is interesting.  I don't think this is suddenly a new requirement or concern for 2015. I think it has always been the case, that consumers are very keen to keep their on line identity secure, their banking details safe and their national insurance or social security number locked up.  However, as more and more devices require and process our personal data, end users are becoming more enlightened with regards to how their data is used and stored.

The Internet of Things takes this to a new level, with many more services, apps and devices wanting to consume, process and potentially redistribute personal data.  End users want to have a clear, simple and transparent method of not only sharing data, but also having the ability to revoke previously granted access to personal data.  We are probably some way off this being a reality, but protocols such as OAuth2 and User Managed Access can go some way to help fulfil these newer requirements.

By Simon Moffatt

Cross-Domain Single Sign-On

A couple of blog posts ago I’ve been detailing how regular cookie based Single Sign-On (SSO) works. I believe now it is time to have a look at this again, but make it a bit more difficult: let’s see what happens if you want to achieve SSO across different domains.

So let’s say that you have an OpenAM instance on the domain and the goal is to achieve SSO with a site on the domain. As you can see right away, the domains are different, which means that regular SSO won’t be enough here (if you don’t see why, have a read of my SSO post).

Cross-Domain Single Sign-On

We already know now that in the regular SSO flow the point is that the application is in the same domain as OpenAM, hence it has access to the session cookie, which in turn allows the application to identify the user. Since in the cross-domain scenario the session cookie isn’t accessible, our goal is going to be to somehow get the session cookie from the OpenAM domain to the application’s domain, more precisely:
We need to have a mechanism that is implemented by both OpenAM and the application, which allows us to transfer the session cookie from one place to the other.
Whilst this sounds great, it would be quite cumbersome for all the different applications to implement this cookie sharing mechanism, so what else can we do?

Policy Agents to the rescue

For CDSSO OpenAM has its own proprietary implementation to transfer the session ID across domains. It’s proprietary, as it does not follow any SSO standard (for example SAML), but it does attempt to mimic them to some degree.
OpenAM has the concept of Policy Agents (PA) which are (relatively) easily installable modules for web servers (or Java EE containers) that can add extra security to your applications. It does so by ensuring that the end-users are always properly authenticated and authorized to view your protected resources.
As the Policy Agents are OpenAM components, they implement this proprietary CDSSO mechanism in order to simplify SSO integrations.

Without further ado, let’s have a look at the CDSSO sequence diagram:
CDSSO sequence

A bit more detail about each step:

  1. The user attempts to access a resource that is protected by the Policy Agent.
  2. The PA is unable to find the user’s session cookie, so it redirects the user to…
  3. …the cdcservlet. (The Cross-Domain Controller Servlet is the component that will eventually share the session ID value with the PA.)
  4. When the user accesses the cdcservlet, OpenAM is able to detect whether the user has an active session (the cdcservlet is on OpenAM’s domain, hence a previously created session cookie should be visible there), and…
  5. when the token is invalid…
  6. we redirect to…
  7. …the sign in page,
  8. which will be displayed to the user…
  9. …and then the user submits her credentials.
  10. If the credentials were correct, we redirect the user back to…
  11. …the cdcservlet, which will…
  12. …ensure…
  13. …that the user’s session ID is actually valid, and then…
  14. …displays a self-submitting HTML form to the user, which contains a huge Base64 encoded XML that holds the user’s session ID.
  15. The user then auto-submits the form to the PA, where…
  16. …the PA checks the validity…
  17. …of the session ID extracted from the POST payload…
  18. …and then performs the necessary authorization checks…
  19. …to ensure that the user is allowed to access the protected resource…
  20. …and then the PA creates the session cookie for the application’s domain, and the user either sees the requested content or an HTTP 403 Forbidden page. For subsequent requests the PA will see the session cookie on the application domain, hence this whole authentication / authorization process will become much simpler.

An example CDSSO LARES (Liberty Alliance RESponse) response that gets submitted to PA (like in step 15 above) looks just like this:

<lib:AuthnResponse xmlns:lib="" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:ds="" xmlns:xsi="" ResponseID="sb976ed48177fd6c052e2241229cca5dee6b62617"  InResponseTo="s498ed3a335122c67461c145b2349b68e5e08075d" MajorVersion="1" MinorVersion="0" IssueInstant="2014-05-22T20:29:46Z"><samlp:Status>
<samlp:StatusCode Value="samlp:Success">
<saml:Assertion  xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsi=""  xmlns:lib=""  id="s7e0dad257500d7b92aca165f258a88caadcc3e9801" MajorVersion="1" MinorVersion="0" AssertionID="s7e0dad257500d7b92aca165f258a88caadcc3e9801" Issuer="" IssueInstant="2014-05-22T20:29:46Z" InResponseTo="s498ed3a335122c67461c145b2349b68e5e08075d" xsi:type="lib:AssertionType">
<saml:Conditions  NotBefore="2014-05-22T20:29:46Z" NotOnOrAfter="2014-05-22T20:30:46Z" >
<saml:AuthenticationStatement  AuthenticationMethod="vir" AuthenticationInstant="2014-05-22T20:29:46Z" ReauthenticateOnOrAfter="2014-05-22T20:30:46Z" xsi:type="lib:AuthenticationStatementType"><saml:Subject   xsi:type="lib:SubjectType"><saml:NameIdentifier NameQualifier="">AQIC5wM2LY4SfcxADqjyMPRB8ohce%2B6kH4VGD408SnVyfUI%3D%40AAJTSQACMDEAAlNLABQtMzk5MDEwMTM3MzUzOTY5MTcyOQ%3D%3D%23</saml:NameIdentifier>
<lib:IDPProvidedNameIdentifier  NameQualifier="" >AQIC5wM2LY4SfcxADqjyMPRB8ohce%2B6kH4VGD408SnVyfUI%3D%40AAJTSQACMDEAAlNLABQtMzk5MDEwMTM3MzUzOTY5MTcyOQ%3D%3D%23</lib:IDPProvidedNameIdentifier>
</saml:Subject><saml:SubjectLocality  IPAddress="" DNSAddress="localhost" /><lib:AuthnContext><lib:AuthnContextClassRef></lib:AuthnContextClassRef><lib:AuthnContextStatementRef></lib:AuthnContextStatementRef></lib:AuthnContext></saml:AuthenticationStatement></saml:Assertion>

If you watch carefully you can see the important bit right in the middle:

<saml:NameIdentifier NameQualifier="">AQIC5wM2LY4SfcxADqjyMPRB8ohce%2B6kH4VGD408SnVyfUI%3D%40AAJTSQACMDEAAlNLABQtMzk5MDEwMTM3MzUzOTY5MTcyOQ%3D%3D%23</saml:NameIdentifier>

As you can see the value of the NameIdentifier element is the user’s session ID. Once the PA creates the session cookie on the application’s domain you’ve pretty much achieved single sign-on across domains, well done! ;)

P.S.: If you are looking for a guide on how to set up Policy Agents for CDSSO, check out the documentation.

Single Sign-On – the basic concepts

What is Single Sign-On?

A good buzzword at least, but on top of that it’s a solution which lets users authenticate at one place and then use that same user session at many completely different applications without reauthenticating over and over again.
To implement SSO, OpenAM (as most other SSO solutions) uses HTTP cookies (RFC 6265 [1]) to track the user’s session. Before we go into any further details on the how, let’s step back first and get a good understanding first on cookies. Please bear with me here, believe me when I say that being familiar with cookies will pay out at the end.

Some important things to know about cookies

By using cookies an application can store information at the user-agent (browser) across multiple different HTTP requests, where the data is being stored in a name=value basic format. From the Cookie RFC we can see that there are many different extra fields in a cookie, but out of those you will mostly only run into these:

  • Domain – the domain of the cookie where this cookie can be sent to. In case the domain is not present, it will be handled as a host based cookie, and browsers will only send it to that _exact_ domain (so no subdomains! Also beware that IE may behave differently…[2]).
  • Max-Age – the amount of time the cookie should be valid. Of course IE doesn’t support this field, so everyone uses “Expires” instead with a GMT timestamp.
  • Path – a given URL path where the cookie applies to (for example /openam)
  • Secure – when used, the cookie can be only transferred through HTTPS, regular HTTP requests won’t include this cookie.
  • HttpOnly – when used, the cookie won’t be accessible through JavaScript, giving you some protection against XSS attacks

Let’s go into a bit more detail:

  • If you create a cookie with“, then that Cookie will be available for an application sitting at as well, and basically for all other subdomains, BUT that very same cookie won’t be available at nor at, because does not match the cookie domain. Browsers will only send cookies with requests made to the corresponding domains. Moreover browser only will set cookies for domains where the response did actually come from (i.e. at the browser will discard Set-Cookie headers with Domain).
  • Browsers will discard cookies created by applications on TLDs (Top Level Domain, like or .com), also the same happens with cookies created for IP addresses, or for non valid domains (like “localhost”, or “myserver”), the Domain has to be a valid FQDN (Fully Qualified Domain Name) if present.
  • If you do not specify Max-Age/Expires, the cookie will be valid until the browser is closed.
  • In order to clear out/remove a cookie you need to create a cookie with the same name (value can be anything), and set the Expires property to a date in the past.
  • In case you request a page, but a Set-Cookie is coming out of a subsequent request (i.e. resource on the page – frame/iframe/etc), then that cookie is considered as a third party cookie. Browsers may ignore third party cookies based on their security settings, so watch out.
  • Containers tend to handle the cookie spec a bit differently when it comes to special characters in the cookie value. By default when you create a cookie value with an “=” sign in it for example, then the cookie value should be enclosed with quotes (“). This should be done by the container when it generates the Set-Cookie header in the response, and in the same way when there is an incoming request with a quoted value, the container should remove the quotes, and only provide the unquoted value through the Java EE API. This is not always working as expected (you may get back only a portion of the actual value, due to stripping out the illegal characters), hence you should stick with allowed characters in cookie values.

Funky IE problems

  • IE does not like cookies created on domain names that do not follow the URI RFC [3]
  • IE9 may not save cookies if that setting happened on a redirect. [4]

How is all of this related to SSO?

Well, first of all as mentioned previously OpenAM uses cookie to track the OpenAM session, so when you do regular SSO, then the sequence flow would be something like this:

SSO Authentication Flow

SSO Authentication Flow

And here is a quick outline for the above diagram:

  • User visits application A at, where the agent or other component realizes that there is no active session yet.
  • User gets redirected to OpenAM at, where quite cleverly the cookie domain was set to (i.e. the created cookie will be visible at the application domain as well)
  • User logs in, as configured OpenAM will create a cookie for the domain.
  • OpenAM redirects back to the application at, where the app/policy agent will see the session cookie created, and it will then validate the session, upon success, it will show the protected resource, since there is no need to log in any more.

Oh no, a redirect loop!

In my previous example there are some bits that could go wrong and essentually result in a redirect loop. A redirect loop 90+% of the time happens because of cookies and domains – i.e. misconfiguration. So what happens is that OpenAM creates the cookie for its domain, but when the user is redirected back to the application, the app/agent won’t be able to find the cookie in the incoming request, but authentication is still required, so it redirects back to OpenAM again. But wait, AM already has a valid session cookie on its domain, no need for authentication, let’s redirect back to the app, and this goes on and on and on. The most common reasons for redirect loops:

  • The cookie domain for OpenAM does not match at all with the protected application.
  • The cookie domain is set to, instead of, and hence the cookie is not available at .
  • The cookie is using Secure flag on the AM side, but the protected application is listening on HTTP.
  • Due to some customization possibly, the AM cookie has a path “/openam” instead of the default “/”, so even if the cookie domain is matching the path won’t match at the application.
  • You run into one of the previously listed IE quirks. :)
  • Your cookie domain for OpenAM isn’t actually an FQDN.

So how does OpenAM deal with applications running in different domains? The answer is CDSSO (Cross Domain Single Sign-On). But let’s discuss that one in the next blog post instead. Hopefully this post will give people a good understanding of the very basic SSO concepts, and in future posts we can dive into the more complicated use-cases.