Archive for the ‘LDAP’ Category

TRESPASSINGIn the maturity model of identity management, we have been through many stages of evolution and may be on the brink of the final stage – context aware identity management.  First it was centralized authorization (directory), authentication (access managmeent, SSO, STS, federation), identity management (provisioning), roles (RBAC), auditing/regulatory (compliance and analytics), privileged accounts management, and finally centralized policy management (entitlements servers).  

The final frontier, once you have mastered all of the above, is context aware identity management.  The user may have all the rights and privileges to access the resources, but they are doing so in an abnormal way.  Call it behavioral security.  My classic example is a company’s CIO may have access to a sensitive data room and may even have their badges grant them access to the data center floor, but one has to ask why the CIO is entering the sensitive data center at  2 AM.  However, a member of the cleaning staff would have the same privileges and would be expected in at 2 am to do their cleaning.

So its all about context.  Having the right credentials and using them in an manner as expected and flagging when they are used atypically.  As of this writing, Bradley Manning is waiting his sentencing for releasing 700,000 classified documents to Wikileaks.  What many miss in this sad adventure is that Pvt. Manning did not “hack” his way into the systems containing this information.  He was hired/recruited, trained, authorized to have sensitive access, and had his access vouched for in several compliance reviews.  The only question nobody asked was why a low level private with clearance was downloading hundreds of thousands of files at one time.  His behavior with his access level should have sent up warning signs.

This type of behavioral monitoring has been around for years and found some success, particularly in the financial sector.  Banks and investment firms have employed adaptive access management tools to work with their single sign-on front ends to their web sites. You have probably seen them when your bank shows you a confirmation picture first and asks you to set up security questions.  What you may not know is the software also “fingerprints” your system (OS type/version, MAC address, IP location, etc.) and starts building a profile of how you access your account. If you do anything out of the ordinary, it may ask you who your second grade teacher was even though you presented the correct user ID and password. Try logging into your bank from your mother-in-law’s computer in Florida when you visit next and you will most likely have to answer some additional security questions because we need to insure its you.

So buried deep in the latest release of Oracle Entitlements Server (try no to thump my company’s products, but this is the only software I know that can do this at this point) is the ability to add to your enforcement policies to make them context aware. The enforcement policies can look at more than just job title and role, it can also look at location, device, time, organization, etc. to make a more informed decision on whether to grant access.

It may be okay that you have privileged access to mission critical servers to issue a reboot command, but, ya know, we are just not going to allow you to do that if you came in through an external firewall using you iPad.  Just not going to happen. You need to be onsite in the data center to do that.

It is particularly helpful when several users have access to the same system, but need to be limited on what they can see. Just saw a killer demo a few weeks back where users of a military application can see a map of the world showing location of current deployments, but the data is filtered so you can only see resources in your theater of operation.  Europeans can only see assets based in Europe, Africans only see stuff based in Africa, etc.  All controlled centrally with one access policy.

To get to this level of context aware security is not easy to do and represents what I believe is the final frontier in online security.  Its the ability to not only control access and authorization, but understand when and how the proper credentials are being used.  Remember that most damaging breaches are by insiders who have proper access.

Read Full Post »

nosql-textGot a question from a customer on if it was a good idea to drop their LDAP directory in favor of a NoSQL repository.  For what they needed to do, they felt it freed them to have a more flexible architecture.  This follows up another client request who wished our directory products were based on a NoSQL data repository.

For those not keeping up with data repository trends, SQL has dominated the standards as a way to retrieve data from a relational database (dumb statement of the month). In theory, it abstracts the underlying repository so SQL could be used to pull information out of any vendor’s compliant product.  It works great in joining information together, such as transactions, from the underlying tables.

But not all data fits neatly into this SELECT, JOIN, table paradigm, including directory objects.  A more object oriented approach to data storage is the right way to go.  inetOrgPerson, the de facto standard of how to store information about a user in a directory is actually made up of several objects that inherent the other. To paraphrase Genisis, Top begat User begat Person begat InetOrgPerson or something like that.  To build an SQL statement that could retrieve or store all the information contained in the inetOrgPerson object would be complicated and complex using at least three joins.

The SQL statement would be complex to build and require the SQL engine to decompose it during execution. Overhead to build the statement, overhead to process it.  Kills performance which is the enemy of a good directory.

Instead, the developer should just be able to build the inetOrgPerson and trigger is serialization into the data repository and let the database figure out how to store the information.  Much simpler and, most importantly for a directory, much faster.

So to get back to the original question, should they pull the LDAP directory out and go with a NoSQL repository directly?

My answer is the typical consulting “it depends”.  If this is a stand alone application and all you need to do is store some key-value pairs, it will be hard to argue against going with the NoSQL repository.  But I would suggest you think long and hard about dropping the LDAP directory layer.

For two reasons. One, LDAP brings more than just data storage.  It has years of standards built into it, such as the inetOrgPerson and the ACI rules and policies to access of the objects.  That would have to be recreated at the database level. Second is the fact that many of the newer LDAP directories out there already are adopting object oriented repositories underneath. One of the main reasons my company Oracle came out with a new directory, Oracle Unified Directory(OUD), is to take advantage of the embedded Berkeley DB Java Edition technology.  As OUD is written in pure Java, it made the underlying repository, and thus the overall directory, faster, more robust, and highly scalable.

Good news is you can take advantage of this NoSQL storage approach, but still treat the directory as an LDAP repository, easing migration and upgrade costs.

Read Full Post »