|
I don't have any wonderful solutions, but a couple of observations. I think the issue of other CP's being able to deal with what we call self-issued materials (1.d) shouldn't affect the decision on how to solve this for the JNDI CP.
I don't think #2 is actually a solution to the problem, but it might help us if we have that in addition to #1 (or something like it). #2 *might* allow us to abstract access control such that it makes 1.c a non-issue. That is, everyone would use IdAS to accomplish the policy administration talked about in 1.c (adding the access control policy that grants userX proxy privs for userY)
Maybe there's something I'm not thinking about in terms of #2 addressing the issue. I suppose that if each CP were charged with enforcing this access control model in cases where it can't simply map and defer to the underlying data store, then it would know to enforce the authenticated user's privileges. This would still require that under the covers, something akin to the LPU being used by JNDI today (where the LPU is guaranteed to always have more privileges than anyone that it is "proxying" for)
Jim
>>> "Tom Doman" <tdoman@xxxxxxxxxx> 01/14/08 5:49 PM >>>
Okay, well, at least they are to me.
Okay, this defect report describes how, when the SelfIssuedMaterials authentication method is used, the JNDI Context Provider remains authenticated as what we've come to call, the Least Privileged User (LPU) configured in the JNDI CP configuration file. Any subsequent calls to IdAS will be done using the authorization rights of the LPU.
There are a couple of ways to fix this:
1. Some LDAP servers implement RFC 4370, Proxied Authorization Control. This control would allow the LPU to perform operations as the identity discovered using SelfIssuedMaterials. Exactly what we want! Unfortunately, there are several issues with this solution:
a. This is not a general JNDI ...
b. Not every LDAPv3 server implements RFC 4370.
c. Each LDAP server which implements RFC 4370 defines its own policy for proxy authorization access rights.
d. None of this helps any other Context Provider.
2. Define an access control abstraction in IdAS (Bug #197373). This might be advantageous in that it'd be the same interface for every Context Provider to implement but there are some potential issues:
a. Any given Context Provider may not be able to fully implement the access control abstraction.
b. It may become a large burden to keep track of this information for each CP, potentially, outside of its native store.
Even if I implemented #1, we'd still have to describe and explain how the LPU works for those directory servers that don't implement 4370. Then we'd have to describe what limitations an LPU puts on the kinds of applications and data that one may want to front with IdAS. So, what LDAP servers are people on this mailing list using? Do you know if they support RFC 4370?
I fear #2 will be a huge undertaking (though, as I included above, Jim has entered a defect for it) with limited functionality but I'd like to discuss if, when, and how if the general consensus is that that is how we should solve this defect.
Thanks,
Tom
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
|
