Showing posts with label Authorization. Show all posts
Showing posts with label Authorization. Show all posts

Sunday, December 30, 2012

Risk-Based Access Control Part Two: Client Side and Administration of VIP

As promised, a follow-up post on managing risk with VIP.   The first part covered the web services call to VIP User Management.  Here we'll cover the fingerprinting of the device.  Simply add a little javascript into your pre-risk analysis page (typically a login page):


<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Login</title>
<script type="text/javascript" src="https://vipuserservices.verisign.com/vipuserservices/static/v_1_0/scripts/iadfp.js"></script>
</head>


A good client side developer might make the SOAP call into VIP User Services might make the web service call here.  I used a server-side intermediary to make the web service call, so I posted the fingerprint data as part of the form:


<input type="submit" onclick="document.getElementById('deviceFingerprint').value=IaDfp.readFingerprint();return true;" value="Sign-In" />
 

I'll cover what I did with the return values, feeding them into Symantec O3 in Part III.  Let's go over the management side here in the meantime.  VIP Intelligent Auth is managed from the same VIP console used for the one-time-pin (OTP) and credential management.

Although Symantec doesn't feature the most knobs and dials of risk vendors, one could argue that the simplicity of the black-box system is sufficient for most risk administrators.  A simple slider to determine the threshold of risk before the request is deemed "risky".


You can also manage whitelist and blacklist IP addresses:

As well as countries on your bad-boy list:


And that's about it.  Symantec keeps most of its risk algorithms black boxed.  Some testing will help you to understand the typical values for risk score (0-100) and how you can factor that into your authorization policies.  

Monday, October 29, 2012

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.

Monday, October 1, 2012

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).