Why Governance isn’t just for SOA – but Identity too!

People often think of security in terms of barriers. But anyone who looks after a barrier knows that its an ongoing process. And managing processes is what we call governance. A few years ago, I would talk to people who had put in place a firewall. They were convinced they were now “secure”. But then I’d ask what process they had to monitor the firewall and its logs. Unfortunately too often a look of “do I have to do that?” crept onto their faces. Without governance, a firewall is no good: if you don’t know someone is making a concerted effort to attack you, they will eventually get through.

It is not just firewalls that require governance. Increasingly I see examples of security issues that also are linked to governance. I think Wikileaks is a good example: whoever did it had too much access (not policy based but simply yes/no) and there was no “alert” that perhaps an unusual access pattern was in operation. Similarly I recently heard of a situation where an employee kept their online work log in for six months after they left the company.

Too many keys, copyright 2011 Jonathan MarshThere are two prime causes for this:

  • Firstly, there are too many identities. Each of us knows we have tens if not hundreds of identities on different systems. And there is no overall control of those identities.
  • Secondly, there are too many places that permissions are checked, or not checked. On the whole we rely on each application to implement permissions and there is a huge lack of consistency between these systems.

Its possible to fix some of these problems with manual governance processes. But even better is to automate them: the least human effort giving the most security.

We believe that there are two key technologies that can help:

1. Federated Identity Tokens

For example – SAML2 – the Security Assertion Markup Language v2 is a standard for XML-based identity tokens. These tokens give us two big benefits: single-sign on and federated identity. SAML2 can help unify as many systems as possible around a single identity. You can configure Salesforce or Google Apps to accept SAML2 tokens from a system driven by your internal LDAP. When an employee leaves, all you need to do is to remove them from your LDAP system and they are automatically shut out of all SAML2 based systems. This is an example of federating the identity from your internal model into Salesforce or Google. Amazingly, unlike most security systems that make life harder, SAML2 actually helps your users, because it gives them single-sign on onto many different websites.

How does SAML2 do this? The key benefit of SAML2 is that the user authenticates to a single “identity server”. Then this server creates a token which is trusted for a limited time by the target. The token can contain a variety of information (“claims”). These claims can be used as part of any authorization process. For example, a claim could assert that the user is logging in from a secure network.

2. Policy-based authorization and entitlement

For example: XACML – the XML Access Control Markup Language – does for authorization what SAML2 does for authentication. It allows a single policy based model for who can access which resources. XACML is very powerful too. It can work in conjunction with SAML2 to create very rich security models. For example, you can allow different access to users who are logged into a secure computer on a secure network as opposed to users coming via their laptop from Starbucks.

XACML does this by being able to capture complex “entitlement” logic into the Policy. The Policy is an XML file that can be stored in a smart registry. For example a policy might state that user Paul may access a salary update process between 9AM and 5PM GMT if Paul is in Role Manager.

 

The title of this blog is that governance is not just for SOA. SOA Governance has been — in our view — an area where the architecture community has learnt a lot of useful lessons. Let’s try to apply the SOA Governance lessons to Identity and Security Governance.

In the SOA world a common pattern for governance is the combination of a Registry and an ESB. The secret to this is:

  • Using policy and metadata instead of code, and managing the metadata in a Registry.
  • Moving towards a canonical model and transforming legacy systems into the canonical model.
  • Putting in place central logs and monitoring.

It turns out we can learn exactly the same lessons for Identity:

  • Using XACML to have a consistent model and way of defining authorization and entitlement using policy instead of hard-coding it into apps and storing these policies in a Registry.
  • Audit Log, Copyright 2011 Paul FremantleUsing SAML2 as a canonical model for Identity and bridging that into legacy systems as much as possible.
  • Using common auditing across your Policy Enforcement Points (PEPs) to ensure a single central audit log.

With this kind of model the governance becomes much more simple and automated. Removing a user’s login permission can remove login from everything. Authorization can be based on policies, which can be managed using processes. Even remote systems like Salesforce will still be included in the audit, because when a user signs in via SAML2, the SAML2 token server will create an audit event.

OpenID and OAuth are alternatives that perform similar and complementary functions to SAML2 and XACML, and are supported by a number of websites and web-based systems.

Good governance is tricky, and an ongoing process. The best way to get good governance is to automate it around simple straightforward approaches. The trio of metadata, canonicalization and log/audit is a great start and putting in place a solution around that architecture is an effective way to improve your Identity Governance.

 

 

Portions of this post have previously appeared in an article written by the author for Enterprise Features

Paul Fremantle, WSO2 CTO
Paul’s blog: http://pzf.fremantle.org/