Ok, so the one case I didn't include would be where the base DN pointed at is different. Rule #3 says that would cause a context to be different. Another observation is that with these rules, if ex5 was always completely consistent with it's replicas, we would say that it's also equal to ex2, ex3, and ex4.
Then to answer Raj's question of why do we need to know whether two contexts are equal: What I'm trying to do is understand what a Context Reference (URI) is, and how two providers can create instances of the same context. Mostly it's just helping me understand what we need in the Context Reference URI.
The next question is this: For any two contexts that are the same (equal), is the Context Reference (URI) the same?
If the answer is yes, then I think we've now established that these do not belong in the URI:
Provider, Factory, Protocol, Host, or AuthN materials.
It's likely that the host in my examples below also doesn't belong in the URI because aliases can be used which, while not appearing equal, actually point at the same data.
So, I think it's useful to discuss/document what constitutes sameness, but to me it looks like there's little to nothing in a Context Reference URI that defines exactly "what" the context is other than some kind of human-readable abstract thing like "urn:higgins:context:personal", "urn:higgins:context:shared", "urn:higgins:context:work", "urn:higgins:context:school"
Jim
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 7/24/06 8:15 PM >>>
Proposed definition of Context "sameness"
Two Contexts are considered to be the same (equal) if:
1. They use the same schema.
2. They share the same auth policy.
3. To a given user (and thus subject to the same authorization policy), they present the same data instances (the same Digital Subjects, Identity Attributes, Subject Relationships, etc)
By this definition:
- ex1 != ex2 because of #3 above
- ex2 = ex3 = ex4
- ex4 != ex5 because ex5 does not at all times satisfy #3 above (and we don't have any notion of versioning)
-Paul
Jim wrote:
We've mentioned the notion of two providers being used to access the same Context a number of times. It makes me ask myself what constitutes sameness among contexts.
Referring to the context examples at the bottom of this mail, I don't know which are the same context, and which are different:
ex1 and ex2 both use LDAP, both start at the same place in the LDAP server's tree, both use the same AuthN materials. Difference is vendor. Let's say the IBM provider maps attributes quite differently than the Novell provider, and the Novell provider follows referrals whereas the IBM provider cannot, thus it's view of the tree is chopped. These may look quite different from the IdAS consumer's POV.
ex2 and ex3 differ only in protocol. Let's say both present the data model exactly the same and have the same capabilities.
ex4 uses different AuthN materials, with the implication being that a different set of data will be exposed (anon cannot see privileged data).
ex5 points to a different host. It's assumed that this host is a replica of eDirLDAPServer.com. The only problem is that replication between these two hosts is loosely consistent. There's no guaranty that the data is ever exactly the same among replicas.
Maybe we're saying a context is defined by its Context Reference (URI). So, whatever the URI contains or points at must be what constitutes a context. If that's the case, we're back to the "what's in the URI?" question
Provider Implementor = IBM
Factory = IBM LDAP factory
Base = ou=employees.dc=ibm,dc=com
AuthN = superuser and credentials
Provider Implementor = Novell
Factory = Novell LDAP factory
Base = ou=employees.dc=ibm,dc=com
AuthN = superuser and credentials
Provider Implementor = Novell
Factory = Novell NDAP factory (NOTE: different protocol, same backing data)
Base = ou=employees.dc=ibm,dc=com
AuthN = superuser and credentials
Provider Implementor = Novell
Factory = Novell LDAP factory
Base = ou=employees.dc=ibm,dc=com
Provider Implementor = Novell
Factory = Novell LDAP factory
Base = ou=employees.dc=ibm,dc=com
AuthN = superuser and credentials
|