Catch me at CSA Congress in Orlando November 7th

I'm going to be speaking at the Cloud Security Alliance (CSA) Congress in Orlando on Nov 7th.  Here is the brochure for the conference:

http://www.misti.com/PDF/174/20920/CSA12%20Bro_S.pdf

The topic is "Enterprise Insecurity...Mobile Devices Collide with the Cloud."  I will be touching on Mobile Application vs. Mobile Device Management (MDM), limitations with the current pure SAML standard when dealing with mobile devices and cloud, preventing side-door access and other timely topics.

If you have some time to stop by and say hi, please do.

Preventing Data Loss to the Wild

I recently got a preview from a vendor's implementation of a policy-based access control integrated with a Data Loss Prevention (DLP) and encryption solution to provide a very compelling story around protection of files being posted to cloud service providers like DropBox and SalesForce, as well as internal content management like SharePoint.    This is especially relevant to existing customers of this vendor's DLP solution or prospective customers of both a SSO/WAM/Federation/Access and DLP solution.

Does that picture give you pause?  The vendor had a number of modes including:

- Encrypt files when being uploaded to these cloud service providers
- Passive DLP monitoring
- DLP classification based on or in addition to encryption

What do these modes mean?  Let's start with encryption in the context of SalesForce.  Say you upload a file in this encrypt only mode.  If someone outside the organization gets ahold of the file through some means, without the key, they would be unable to read it.   The vendor has a hosted & managed PKI management service, so there will be a very light footprint for entry.

With DLP, policies can be applied within the policy-based access control system.  The access control system can block or redact content based on DLP rules that are applied.   DLP renders a verdict that contains a DLP score.  Policies can be applied based on that score for instance, to block or redact content.  Typically an organization would start out in passive mode to monitor activity and give them a way to tune the policies without adversely affecting operations.

If you're evaluating a SSO & access control solution, you should consider this solution in your evaluation criteria if there's content that you worry about leaving the organization.  The vendor indicated that it would be available by end of 2012 calendar year.

How do I Prevent Side-Door Access?

Despite all of the best laid plans of an organization, it seems like lines-of-business and individuals are still going to the internet to leverage services that put the organization at risk.  "This file's too large for email, I'm just going to throw it up on my personal Box account."

That's just the accidental scenario.  There's the more nefarious 'Kinko's run', where the terminated employee heads to the local internet shop to download the contact list from online CRM that hasn't been de-provisioned.   Like most solutions, there's a people/product/process side to making things easier for employees, while keeping employers out of trouble.

From the product side, many cloud identity providers can leverage SAML to prevent side-door access to cloud service providers.  The Service Provider always redirects back to the enterprise for authentication.  Assuming the employee has been removed from Active Directory or whatever mechanism the Identity Provider uses, access is cut off.

For many of the SaaS Service Providers that don't support SAML yet, some cloud identity solutions provide Form POST SSO.  This Form POST can be paired with a provisioning system to prevent side-door access using a technique called 'password cloaking'.    Essentially the user's password at the service provider is unknown to the user.  It is periodically reset by the provisioning tool to ensure that it in sync between the Service and Identity Provider's credential vault used for SSO.

Users authenticate to the Identity Provider with their enterprise credentials and get SSO to the Service Provider without knowing the password to that account.  This approach isn't without its problems.  Reset password wizards at the service provider can be used to circumvent the cloaking mechanism.   This is where the people and process come in.

If users can be provided a better experience in getting access to shared file services like Box through the  enterprise account that is governed by a Cloud Identity solution, most would opt for that approach, knowing that they're being a good citizen and it's easier anyway.   Proper education about available services will get critical mass necessary for adaption.

Just-In-Time Versus Asynchronous Provisioning

There are multiple options for getting identities into and out of external service providers (SP).  This is often dependent on what the SP supports.  Some SPs support Just-in-Time (JIT) Provisioning, which means that the service provider will consume SAML attributes upon login and either create the user if he/she doesn't already exist in the SP's user store, or update the local account if any of the attributes differ from what is sent in the assertion.  This is secured by the inherent trust of the SAML authentication.  The downsides of JIT provisioning are that you typically cannot de-provision a user.

Asynchronous provisioning utilizes some kind of scheduled job or user interactive method of synchronizing identities from one or more sources to the service provider.  This typically involves a polling of the authoritative user store and pushing any adds, deletes, inactivates, changes, etc. into the target.  The target service provider must provide some kind of provisioning service in order for this to work.   Many of the provisioning vendors have implemented connectors/adapters for SPs like Google, WebEx and SalesForce using their respective APIs.  Each of these are one-off implementations and most SPs don't provide any kind of public provisioning hooks today.

An Oasis standard called SPML for provisioning was created over 10 years ago, but has lacked in adaption (so much so that I won't bother to even spell out the acronym).  Its failure was likely in its lack of granularity for updating profiles and the general complexity of implementing a SOAP-based service.  Simple Cloud Identity Management (SCIM) is a likely successor for SPML.  Plenty of information on SCIM at http://www.simplecloud.info, but SCIM's use of REST and the timely need for it with the proliferation of cloud service providers will drive higher adaption.

This matters because the natural progression of these cloud providers will be the aggregation of these services into packaged offerings.  Identity propagation will be key to enabling these aggregations and you can't propagate identity easily without having an account at the SP.  Thus, end-to-end user lifecycle will require that accounts are provisioned and de-provisioned from the SPs from that 3rd party aggregator.   SCIM enablement will be a big land grab for provisioning vendors going forward.

Example of Context-Based Authorization Reducing Number of Policies

Access control requirements have morphed from URL to group-based policy to an attribute/risk/role-based object and data model.   Objects in portals no longer have unique URLs (WebParts in Sharepoint for instance).  Policy enforcement of web services, REST and data are becoming more prevalent as requirements.  A platform that only does HTTP cannot be centralized if it doesn’t have a story for these other protocols.  

Trying to model authorization with a traditional Web Access Management (WAM) product is tedious, especially if it can't accept contextual attributes from the calling component or Policy Enforcement Point (PEP).

Let's say you have a financial institution that has a number of reports:  Summary and Detailed, each with multiple regional (East and West) and content (Stocks and Bonds).  2x2x2=8 different reports.  Let's pretend we have the following actors:

Name	Type	Level	Region	Qualified
Charlie Gild	Customer	Gold
Chad Silva	Customer	Silver
Ed Easton	Employee-Broker	N/A	East	Stocks
Ender Wiggins	Employee-Broker	N/A	West	[Stocks, Bonds]
Paul	Partner	N/A

The institutions have the following policies:

• Employee-Brokers can only view account reports within their own region and what they are qualified to trade (stocks, bonds, or both)
• Gold-level customers can view detailed and summary account and can transfer funds up to 20K
• Silver customers can only see summary account info and can transfer funds up to 10K

In order to implement this with a URL-structure today, one would need a large number of policies:

PERMIT:
/summary/bonds/east -> [employees.region=east AND employees.qualified=bonds | both ] OR partners OR customers
/summary/stocks/west -> [ employees.region=west AND employees.qualified=stocks | both ] OR partners OR customers
/summary/stocks/east -> ...
/summary/stocks/west -> ...
/detailed/bonds/east -> [ employees.region=east  AND employees.qualified=bonds | both ] OR customers.level=gold
/detailed/bonds/west -> ...
/detailed/stocks/east -> …
...

Contrast this with context aware authorization:

PERMIT (view, Employees, Reports) if Report.Type IN [Subject.Qualified] AND Report.Region = Subject.Region
PERMIT (view, Customers, Detailed) if Subject.Level=gold
PERMIT (view, [Customers, Partners] , Summary)
PERMIT (transfer, Customers, Funds) if amount < 10K
PERMIT (transfer, Customers, Funds) if Customer.level = gold AND amount < 20K

Dynamic context-based policies are must more dynamic and easier to manage.  These policies assume that the PDP can:

1) Accept context from the PEP that can be used in the policy.  The Report.Region is an example of the context attribute which is known by the content management system that holds the report as metadata.

2) Lookup attributes at decision time from a PIP.  Customer.level is an example of a persisted entitlement for the Customer.

3) Evaluate a hierarchy of resources.  Detailed and Summary would inherit from 'Reports' in the first policy above.

Let's put it to the test:  Let's say Ed Easton requests a detailed east region bonds report.  The first policy would by most applicable.  The last part of the constrain would return true as the Report.Region (East) matches what Ed has in the directory (East).  However, the Report.Type (Bonds) is not in the list of equities he is qualified for.  Ed is denied access to that report.  

These examples are a little contrived, but hopefully they help illustrate the point.

Comparing OES 10g with OES 11gR2

Oracle Entitlements Server has been through more name changes and re-writes than any other product in history.  Okay, that's probably a reach, but it's had its fair share.  The most recent release is OES 11gR2 (11.1.2).  Most implementations of OES are version 10g, which is based on the BEA implementation.  Oracle set out with some ambitious goals for OES and have met a number of milestones in this rev.  This post outlines some of the differences. Documentation home for 11gR2 is here.

Conceptually, OES 11gR2 is the same:  You have a standalone Policy Decision Point (PDP) that handles authorization requests from web service and RMI client (language agnostic) and a Java-based embedded PDP/PEP (The 'E' being Enforcement) API for any Java container.  Both models can take context in the form of attributes from applications and use the context values in policy decisioning.  Both models can pull attributes from Policy Information Points (PIP) like Database and LDAP, usually querying on Subject.

Implementation of this policy engine differs significantly, however.  Some of my favorite improvements:

• Constraint editor: Where in 10g, you had a free-form text box where you had to know the various expression language and functions, in 11gR2 you have an editor that gives you list operations, drop-down boxes for type-specific expressions, and lists of available attributes.
• Policies can be written directly against external groups and users:  In 10g, you basically had to replicate users and groups in the OES 10g Identity Store in order to compose policy against these entities.  In 11gR2, you can browse external directories and write policy against external users & groups.
• Improved runtime and management APIs: The PEP API in 11gR2 has been greatly simplified, without sacrificing functionality.  The BLM API in 10g was simply a mess, versus the 11gR2 Management API, which is intuitive.

Some potential reasons for not moving to 11gR2:

• The 10g Policy Administration Point (PAP) ran on Tomcat (though it wasn't a pure Java EE solution) as well as WebLogic, where 11gR2 is only WebLogic today.  You could use a number of non-Oracle databases as well, where 11gR2 only supports Derby and Oracle.  
• The WebLogic authorization story changed significantly in 11gR2.  Instead of leveraging the Authorization and Role Mapping providers in WebLogic, OES plugs in at the JPS/OPSS layer.  For those using OES for WebLogic container authorization, this could be a challenge (not that it was frictionless before).  Long-term, the 11gR2 solution is better, with auto-deployment of applications into OPSS automatically being managed by OES when they share the same policy store.  

Oracle has definitely left its fingerprint on this revision of OES, with probably little of the CrossLogix & BEA codebase remaining.  Where some other Oracle ADF consoles can be pretty clunky, the Authorization Policy Management (APM) console for OES is fairly good, IMO.

While the initial 11gR1 (11.1.1.5) release had some missing pieces from 10g such as Policy Simulation and SharePoint support, the 11gR2 release has tidied up those deficiencies.  My wish list going forward is better tooling for development, especially in the area of data security (handling multiple predicates in an obligation on the client side).