|
I'm one of the people who failed to standardize on an access control model for LDAP. A number of us (Ellen Stokes, Ed Reed, Bob Blakely, Steven Legg, Kurt Z. etc.) worked on this for a span of about three years, and we never went anywhere but in circles. The circles weren't even concentric, and I'm not sure they even quite met at the ends. Steven Legg finally adapted the X.500 access control admin model to LDAP. The problem is, like replication, everyone has already done it in their own standard way, and it's hard to make the old, hard-coded stuff work along side new standardized stuff.
Even if people felt like it was a good idea, I'm not sure how many vendors are willing to spent the $ to rev. My feeling is that we *have* to implement authZ at the IdAS or higher layer because there will always be some CP's backing store that doesn't authZ the way we want.
Jim
>>> Phil Hunt <phil.hunt@xxxxxxxxxx> 01/30/08 3:32 PM >>>
Having proxied just about every LDAP server on the planet, support is
very inconsistent indeed. Even if an LDAP server supports ProxyDN,
it's application to access control may vary as well. Part of the
problem with LDAP is that access control itself was never standardized.
Somehow there needs to be a do-over on this one. Maybe privacy is
enough of an impetus to revise or replace ProxyDN and rejuvenate
interest in it. My thought is we need a control to take on broader
transaction metadata - only part of which could be application and
subject credentials.
The second requirement is to propose XACML (or a profile of XACML
like AAPML) be optionally supported in LDAP. This is the policy
engine that would consume the metadata mentioned above and brings
some level of consistency of expectation for what happens from the
perspective of policy.
Phil Hunt
Oracle
On 30-Jan-08, at 1:05 PM, Tom Doman wrote:
> All,
>
> Which LDAP Servers have you used behind the JNDI Context Provider?
> Does it support RFC 4370, the proxy authorization control?
>
> Me:
>
> Novell eDirectory, no.
> Test LDAP Utility, no.
>
> Thanks,
> Tom
>
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
|
