The nervousness of finance sector and public sector customers regarding the deployment of cloud-based applications continues. It appears a lot of this nervousness comes from the opportunities for espionage, subterfuge and other bad-things

I’ve had conversations with a number of customers now who have expressed an interest in federating certain applications in the cloud but the thing that holds them back is this: with federation, security tokens issued by federation servers actually traverse the users’ web-browsers. Even with encrypted tokens and an encrypted channel such as SSL, there still exists an opportunity for unauthorised viewing which is something embedded in to policy, legislation and various rules and regulations they are obliged to follow. Many of them must follow this policy for certain classes of staff such as temporary staff, temporary contractors, pert-time staff and so on. Nothing they can do about it – “them’s the rules” (sic).

However, all is not lost. There is a feature in the on-premise federation server (Active Directory Federation Services 2.0 – ADFS 2.0) half of the equation called an issuance rule. Before I describe it – you might like to spend a few moments understanding how federation works, but this is the scoop.

Federation involves a dance between the client web-browser and the various services. In this case we are talking about the cloud application(s), the App Fabric:Access Control Service (ACS – which is really a cloud-based federation service) and the local ADFS 2.0 server. When a user with an on-premise AD account tries to access a cloud application that is protected by federation, a number of redirects occur and the client ends up requesting a SAML (Security Assertion Markup Language) token from the local ADFS 2.0 Server. This is where the opportunity for unauthorised viewing occurs – although I’d argue in reality, trying to decrypt a SAML Token would be more than a minor challengette.

ADFS 2.0, on-premise can be set up to only issue SAML tokens according to a set of rules. You can create a really simple rule which only issues token to users who are members of a certain security group. You can alternatively set a rule which will not issue a token to somebody who is a member of a certain security group. Alternatively, the issuance rules could issue a token based on some other attribute that is set on the user object. Perhaps the job title or the department.

So an ADFS 2.0 service that is federating users to cloud-based applications could deny say, temporary contractors, before they even get to the cloud application. It’d be a simple matter of creating a security group – “Non Cloud Users” and adding the right members of staff to that group. On the ADFS 2.0 Server, an issuance rule would be set up to deny the issuing of SAML token to anybody in the security group.

The experience for the user would be thus: they’d type the application URL and a few seconds later, they’d land at the ADFS Server and be hit with an Authorization Failure error message. The message is a page from IIS which could be customised to give more of a clue – “You are attempting to use a cloud-based application. Temporary contractors are not permitted to do this. If you need access to the application, please email requests@govdept.gov.uk”.

In the case of the odd exception here or there – it’s just a simple matter of removing them from that security group.

The interesting thing is that the SAML token is never issued and the “dance” terminates at that point. It’s different to putting an authorization step in the cloud application which denies access to the user based on some claim within the token – because the token will have traversed the browser and therefore a theoretical opportunity for unauthorised viewing existed. Perhaps with a copy of fiddler running, the user could view the token.

If you find yourself cornered by this legislation, then ADFS 2.0 issuance rules could just be your saviour.

Planky