If you front-end data (or a data store) that you don't own (or don't have control of), then you need to replicate/sync data (instead of virtualizing the view).

And then asked if this is a litmus test for Meta vs Virtual.

My answer is that it depends.

This is because Sundaram's statement is a false assumption though it's a common belief.

It's a common belief because people want to be "in-control" of data and feel that unless they control everything, they are not truly in control.

This of course is patently false - we have mechanisms (such as contracts) to deal with boundary control issues without needing to actually directly control everything

And this is reflected in the fact that many (if not most) virtual directory deployments - the team that runs the virtual directory does NOT own the data sources they are connecting to. They systems they connect to are often run by different teams usually with different management chains. But virtualization works because those systems are already designed to be used by external client applications with proper level of Service Level Agreements & availability.

And virtualization is a way to make the most out of these existing capabilities.

Where "meta-directory" makes the most sense is really two cases:

1 - You want to reduce the number of storage systems in particular different LDAP servers. Thus you could collapse many ADAM, Sun, Novell, openLDAP, etc into a single enterprise-class storage system such as Oracle Internet Directory.

2 - You need a standardized, provisioning system to meet business process & compliance requirements. This is the environment which Oracle Identity Manager fills.

9. I would use the same law and force Larry Ellison to make Oracle contribute more to open source. 

First - why single out Ellison and Oracle? Does he feel others like Microsoft or IBM or CA have done enough? And if so - what have they done for comparison.

Second - I would like to point our Oracle's contributions to Open Source. Most people are probably not familiar to the work we have done.

Start with our Open Source Site.

But just to give a summary:

1 - Oracle contributes heavily to Linux to help the database in particular work better. This is why we were able to offer Oracle Enterprise Linux.

2 - We have put significant effort - in terms of drivers and related work to various projects including PHP, Ruby, Spring and of course EclipseLink (aka open-source of Toplink)

3 - We effectively donated our entire next-generation UI library (ADF) to Apache to help provider a richer platform for Web applications.

4 - We doing all of the reference work for IGF in the open at openLiberty.

5 - It's now possible to run Oracle software on Amazon EC2. This is particular useful when it comes to the database - you can now have a full EE database instance running in 5 minutes without having to fiddle with any kernel or related parameters.

So James -what specifically do you want Oracle to do more of? And what would be the value for you to do so?  If you have specific items I'm happy to hear them & communicate them to the appropriate people.

Pete Finnigan - Oracle [database] security information -- A page with various utilities to help test your local Oracle password security and tools to help with auditing the database.

So for example:

alter user hr identified globally as 'cn=Mark Wilcox,cn=Users,dc=ovddemo,dc=com';

Should allow you to then login as Mark Wilcox using his uid value (e.g. mwilcox).

I'm sure I read that in Knox's book before but it didn't sink in until I was asked about this at OOW last week.

Passwords -- This blog post from the "Blown to Bits" blog talks about problems with passwords. On a personal level - you should have a random password. No words. Just mix of characters. From a developer perspective - do not write your own login code. Almost all frameworks now have their own login subsystem - leverage that. It will allow you to focus on code that is actually core to your business application. Or as I would think - I would not want my friend Quan writing my UI but he knows how to write awesome security code. I know my friend Josh knows how to make awesome looking UI - he shouldn't be writing my security code. And from an enterprise level - make sure you are adopting  comprehensive access products such as Oracle Access Manager suite.

"Using Yahoo! Login Mechanisms for Desktop Applications" -- If you want to use Yahoo! for user password management this might be useful to you.

Criminal probe of ex-Lottery employee Launched  -- Basically another data leak problem. Remember - when writing apps to make sure you allow for proper auditing. Also make sure to put in hooks that can allow for access controls to be written using a standard like XACML (such as provided by Oracle Entitlement Server). And if you are storing data in a database make sure the application can work with strong security measures like Oracle Database Vault and Transparent Data Encryption. And - if you managing/installing database - make sure you enable these features if your applications can support them.

Schneier On Security -- Bruce Scheier who is the expert on security - has released a new book. I believe it's a collection of his columns, so if you are a regular reader probably nothing new. However, if you are new to this field - you should get a copy. As well as his previous book Beyond Fear. Or if you are up to speed on these books - then be sure to read The Unthinkable: Who Survives When Disaster Strikes - and Why.

The purpose of that blog in compared to mine is that we will focus on customer stories and higher level use cases. While i continue to be more technical here.

"For Your Browser Only" -- Reminds developer's that if you are writing cookies from your server code to remember to mark them "HTTP Only". This dramatically reduces the surface area for cross-site scripting attacks. I would also add that other techniques - such as using a standards-based framework for authentication/session management and risk-based access control like Oracle provides via Fusion Middleware and the Access Management Suite will add extra protection.

Security Researches Uncover Spring Framework Vulnerabilities  --  Some researchers have found vulnerabilities in the popular Spring framework.

What Californians Understand About Privacy Online -- A paper showing how big the gulf is between the average person's perception of how their privacy is protected and the reality . One could of course make a joke about what do you expect from people who elect "The Terminator" their governor  but it is a real problem.

SQL Injection issue in :limit and :offset parameter -- A two-fer this week - security issues in two of the most popular frameworks out there - Spring and now Rails. I give credit to the author for trying to help raise awareness and in general I think adopting frameworks (in particular standard - whether that's "Standard" like JSF or a "standard" like Spring/Rails) make you more productive - and yes, secure.

5 Features Your Login System Must Have -- An interesting article for those who are still "rolling their own system". Of course for an enterprise - I'm not sure of any valid use case where that would be a good idea - there's too many good products out there such as Oracle Access Management Suite that can do this for you without needing to become a SSO developer. If you are working on a consumer site - then at the very least, you should adopt something like OpenID or Infocards so that you are not managing passwords.

As I used to say to my "How to build web page" students when I taught - "The only difference between a novice and a guru is the number of people who know when you screw up".

Sorry for any confusion if you followed the earlier links.

The database supports multiple models of authentication.

They are:

• username and password
• digital certificates (aka x.509)
• Kerberos
• RADIUS

The first three are supported by EUS. The last - RADIUS is not.

Username and password is the easiest but does mean that in EUS we have to have a MD5 or SHA1 password stored in the enterprise directory. For Active Directory we have a DLL that uses Microsoft's Password Notifier API to do this for us since AD doesn't do this automatically. For Sun (and Fedora though we haven't officially certified it) the standard userpassword attribute is already hashed properly.

If you are using Kerberos the upside is that you don't need to exchange passwords. Instead the client gets a ticket from the KDC (these days that's likely to be Microsoft AD though I have run into MIT recently) and then the ticket can be used to validate their credentials against the database (this is a simplification of Kerberos. But if you really want to know more you can read the details ). In Kerberos the database verifies the credentials. It only uses EUS to map the user to a database schema and database role.

Now to answer some specific questions - which I can update later:

Q1 - the LDAP listener is not Kerberos ( authentication ) enabled?

A1 - Correct, OVD currently does not support Kerberos authentication. This is not generally a limitation since no common LDAP client application that I'm aware of requires Kerberos authentication. Also Kerberos protocol does not easily open itself up to virtualization. Perhaps this will change when the world starts to adopt STS technologies.

Q2 - the LDAP adapter act as a client and is Kerberos enabled?

A2 - Yes, OVD can take a simple bind (e.g. username and password) from an LDAP client application and verify that password against Active Directory using Kerberos. This is useful if a company doesn't have SSL enabled on AD (but has SSL on OVD) and wants to securely validate passswords against AD.

Q3 - I can't use my Kerberos ticket ( obtained while login in to a windows domain ) to authenticate to OVD and do a query" ?

A3 - This depends because LDAP is like database - most of the time end-users are not connecting directly to the system - they use client applications. If the client application is web-based and configured to do Windows SSO - then yes. If it's a 3rd party application that cannot, then you will need to re-type your credentials. Even if we could accept Kerberos tokens - OVD (just as ANY other Kerberos enabled application) is dependent upon the client application to support it as well. This is why Kerberos never took off in great numbers prior to the release of Active Directory (which gave everyone who ran Windows a KDC whether they wanted it or not) and the Web.

This year I will be presenting at the main conference with one of our customers - The State of Delaware.

The presentation is:

Session ID: S298925
Session Title: Using Oracle Virtual Directory to Integrate Microsoft Active Directory, Oracle Database, and Oracle Applications
Track: Identity Management
Room: Golden Gate C3
Date: 2008-09-24
Start Time: 13:00

The State of Delaware will be going over their implementation of OVD with PeopleSoft. And I will be providing the general overview of OVD & identity virtualization.

I am also planning on presenting at the Unconference. I say planning because unlike the traditional OOW conference, nobody knows who is going to present or when until each morning when people post the topics & get slotted. I think it's useful for getting topics posted that are emerging or emerge during the conference itself that otherwise wouldn't have a forum. It is however, slightly confusing to the uninitiated since I had to spend a day with management last week explaining to them that I couldn't guarantee when or where my Unconference presentation would be delivered :).

The Unconference presentation will most likely be our first demonstration of our "Identity Beans" API. Identity Beans is our current internal name for our implementation of the IGF Attribute Services API. I wouldn't say "internal name" to mean "code name". Rather a reflection of the need for a less wordy name for "IGF Attribute Services API" which the IGF team also recognized. I had dinner with Prateek Mishra last week and we bounced around a couple of other ideas including perhaps having one name for the Oracle Java implementation and another for the API specification.

The quick summary on Identity Beans is that this an API that we believe will make it simpler to use identity attributes. Barring some unforeseen issue this is the API that Fusion application security will use to access the identity information exposed by Fusion applications (such as HR ) and automatically linked with the enterprise directory (in most cases we assume this will be AD).

This is the API that will generate CARML mapping files - though we will likely ship with a set of pre-defined mapping for Fusion apps data. And while it does generate CARML (or can generate it's code from a CARML file) - the goal is that this is like the XML mapping files in Hibernate or Toplink - there for application consumption only. Nobody should ever see (or edit by hand) XML in our GA release.

I will be blogging more about "Identity Beans" over the next few months which will show how this makes secure identity development quicker and easier.

Among the advice - make sure systems are patched, verify the DNS of your ISP is working properly and to double-check the hostname of their OpenID provider.

That is a tall order even for the most technical people. I mean I'm a geek among geeks and I don't think I could accomplish those steps.

But it does give me an opportunity to write about how strong authentication and risk-based access control could help here. Currently we have a product (Oracle Adaptive Access Manager) that provides both functions.

OAAM allows you to use a virtual keypad to enter username and password credentials. This virtual keypad includes such features such as using a background image that you chose (or perhaps chosen for you in an internal environment). It also has other features such as a timestamp, showing a key phrase in the image and the image moves every time it is refreshed. Also the keypad can be virtualized (e.g. driven by your mouse) so that it makes it darn near impossible for a keyboard logger to capture your password.

If more OpenID providers used something like OAAM then it would be much harder for a rogue OpenID provider to be configured.

Additionally risk-based access control (another OAAM feature) would help OpenID relying parties make better access control decisions for a linked OpenID. For example based on prior activity it could assign risk factors (e.g. normally you accessed from an IP in Dallas, but now we're seeing IP access from Outer Elbonia, maybe we should alert a customer care rep to call you before moving that money).

These same principals could also be applied to any other federation scenario including SAML or Liberty based federation like we provide via Oracle Identity Federation.

Of course OAAM has benefits within enterprises who are not using OpenID or SAML but I just wanted to point out some tangible steps people could do to help secure OpenID beyond training people to become DNS engineers.

But I wanted to let people know that we will be having OVD customers present at the upcoming DigitalID World conference.

They will be presenting as part of the panel "Lessons from Successful Virtual Directory Deployments" - Wednesday, September 10, 11:25 a.m.

---

I'm interested that you only talked to the mechanism of modeling information cards/OpenID in LDAP - and not the data model.   Seems to me the schema is pretty important too?

To my knowledge, there is no commonly used/understood schema for the storage of data stored during information card and/or OpenID transactions - I think it would be useful to create & promote such a thing, and to do it soon, before everybody creates their own. 

Just my 0.02c :)

Cheers,

Pam

---

Personally I don't think this is that big of an issue. This is because we have been dealing with this via SAML for a long time so I guess it just feels like an "old" problem to me.

Identity Providers - for identity providers they are likely going to pull this data from an LDAP source anyway. A virtual directory can help because it will make it easier to aggregate data from across repositories in the enterprise/organization and do any data transformation.

Service Providers - for service providers it can be a bit more tricky but it is at least partly a business issue not a technical one. The business issue is what do you want to do with the attributes. This is not a simple answer. 

For example - imagine you are an online florist. And you want to take advantage of this user-centric stuff to help manage both promotion codes and the order processing. For promotion codes, you might start using OpenID for example as a simple way to establish the business relationship. For this - you only really want to use OpenID to help make it easier to do the promotion code exchange instead of having to have people remember obscure codes. In this case, you don't really care about the data, you just want the establishment that they have come to you from one of your partners.

However, for remembering/tracking customer visits they may want to use user-centric system so they can avoid managing passwords. In this case - the attributes you do want to keep - at least temporarily. And by having them in LDAP makes it easier to use them by other applications.

In that scenario - you could choose to link to an LDAP record and thus it becomes "permanent" or you could choose to just make the data "transient" and let it be refreshed on each visit.

In either way directory virtualization helps because you can simplify mapping of the user-centric attributes to whatever LDAP schema you want (or have). For transient data  - you will want the data to be truly transient and not persistent. To accomplish that - you should use an in-memory data storage system such as Oracle Virtual Directory plus Oracle TimesTen. TimesTen is Oracle's in-memory relational database. This would provide simple to manage, low-latency data store that is easy to configure to be truly transient. By combining with OVD - you can leverage standard LDAP integration with both the "user-registration" (even if that is just on-demand data load by your user-centric SP code) and access control. ]]> http://blogs.oracle.com/mwilcox/2008/07/openid_infocard_and_ldap_schem.html http://blogs.oracle.com/mwilcox/2008/07/openid_infocard_and_ldap_schem.html InfoCard LDAP OpenID Wed, 16 Jul 2008 15:01:18 -0800 Most of June and July has flown by. And of course the time I had to actually blog - we were upgrading the blog system so by the time it was live - I didn't have time.

Anyway - I think Clayton covered pretty much most of what I would have said at high level on the meta-directory feud.

One element I would point out in this continuing quest by James and others that seem to live in a world where AD is the one and only directory and I guess never have to deal with customers or subsidiaries or mergers or acquisitions (or maybe all of their kids college funds are only in MSFT stock??) - the fact is that for many organizations, there are attributes that are mastered in HR that may not exist elsewhere.

For example - cost center and manager. You might want to use that information to make an authorization decision on.

While you can - via provisioning system like OIM copy that data into AD - by doing so means you now burden your  Windows admin on managing the data. Which has its own implications - for a single department, it might be manageable. But for an organization that is spread over multiple locations - that data must be replicated and that can take several minutes or hours.

Frankly there isn't any reason for this.

You could simply use identity virtualization to link (what we refer to as a split profile) your username & password in your enterprise directory (like AD) to the record in the central HR system. This could be pulling data from HR or it could be reading it from OIM.

The benefit of this is that you only have to manage, secure and make highly-available that data in a single location. Worried about what happens if that system is down for upgrade or concerned the database isn't optimized for queries -then you can use Oracle TimesTen (aka 11g DB In-Memory cache) to offset this.

And because you are leveraging identity virtuailzation it makes it easier to secure access to the sensitive data because you can specify which applications are making queries on the data and then periodically audit them to insure they are following your rules. But my belief is that if the data is available as a service - people won't copy it because it will be easier to just use it on the network.