[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Groups revisited
>> When a CU authenticates to the CS the credentialling system will output
>> series of UPNs for that mechanism and set of credentials. So what is
>> prevent that authentication mechanism from including a UPN that both
>> Frank, Steve, Doug, Pat and Alex have that is, say,
>> "CAPEditors@xxxxxxxxxxxxxxxxxxxxxx". This is in effect a group UPN
>> all 5 of them share it.
>I don't think I understand. Are you saying that the CS would have to
>thru it's directory and find all the groups that reference the UPN that
>is presenting for you?
When I AUTHENTICATE with my CS, the credentialling process will result in
1 or more UPNs being 'spat out' if the process works. Lets say that when
Frank AUTHENTICATEs with his CS, it (his CS thanks to the authentication
mechanism) says that the pair of UPNs Frank_Dawson@xxxxxxxxx and
CAPEditors@xxxxxxxxxxxxxxxxxxxxxx are 'valid' identities for Frank. He
can use them as part of VCARs or wherever else we allow UPNs.
>I guess it would then keep these group references for
>VCAR evaluation and if asked, return these group references to the CU so
>it could use them for VAR create/edit?
The CS _really_ should keep all the UPNs that are spat out for VCAR
comparison, etc. That way, if there is a VCAR on a paricular event in the
calendar that has a VCAR that only allows
CAPEditors@xxxxxxxxxxxxxxxxxxxxxx to read or edit it then Frank should be
able to access that entry. Just because Franks "primary" (ugh, for lack
of a better description so do not take literally) UPN is
Frank_Dawson@xxxxxxxxx does not mean that he has to do nasty things like
switching identities to be able to access an entry that does have
CAPEditors@xxxxxxxxxxxxxxxxxxxxxx on the VCAR. The CS should do this
equivalence for him!
>Since group names are not usually that
>descriptive, the CU should also be able to show the user the list of UPNs
Smack the group UPN creator up side the head. Groups are much more useful
if their are descriptive than if they are just mangled sequences of
seemingly random junk. Sometimes they are not easily distinguished from
that of a single CU (ie: postmaster@xxxxxxxxx is probably shared among a
couple folks even though it could be just 1 person).
Im still a big KISS advocate and Im not sure we need/want to have the CS
do group expansion by request. That sounds like a directory issue really
rather than a C&S one. Just as a CUA would probably do some kind of
lookup (ie: LDAP, etc) on Frank_Dawson@xxxxxxxxx to get some info Frank,
the same can and probably should be done by the CUA for the other UPN.
In addition, I think the CS should fully unwind nested groups for the
fairly obvious reason that ANY nested group could be on a VCAR. As such
as long as Frank is a member of a nested group he should be granted/denied
>> The UPN can then be used as part of a VCAR to give them write access to
>> particular calendar or entry. When any of them try to modify the
>> particular calendar or entry the CS can check their list of UPNs to see
>> they have the proper rights.
>This assumes that your set of group's matches the set of group's for
>user. This may not be the case for personal address book groups.
Personal address books cannot be used by the CS to enforce or expand group
UPNs during AUTHENTICATion. Besides being a BIG security hole, its not
feasible to even consider HOW the CS could safely get the info from the
CUA and really trust it.. I dont want to murky the waters by talking
about local replicas of the CSs address book (or partial replicas, etc).
Thats OOB for CAP I think. For the CU to create their own group UPNs that
the CS can use, it would have to be done in such a way that the CS can
trust the data (ie: via read/write control to a shared LDAP server, etc).
We can dive on some of the nitty gritty issues later but Im trying to see
if the higher level view/logic I posted originally is accurate...
>As I see it, the CS must evaluate all VCARs associated with a particular
>calendar, expanding groups down to their individual UPN's. While it's
>this evaluation/expansion, it will try to match your UPN with a VCAR
>are allowed access or it runs out of VCARs to evaluate/expand.
We are of similar thought I think but you are doing the expansion in a
different way then I proposed. If the CS determines ALL the UPNs I am
synonymous with when I AUTHENTICATE then it does not have to expaned EVERY
VCAR on every ACCESS to try and find a match for my 'primary' (sic.) UPN.
Its much much cheaper to take the hit up front than for every
request/response that needs to be done. As long as ANY UPN in my list of
identities matches the VCARs then that VCAR is applied to me. That only
drawback is that a change to a group UPN wont take effect until I
reAUTHENTICATE. Typically though this is not such a big deal and can be
handled by some good upfront CS architecture for handling change
>I'm not sure I like this approach. This forces CS vendors to support
>The approach presented by the Boston draft additions makes group support
>optional, i.e., the CS must still respond to EXPAND/LOOKUP but if it
>support groups, it would always return the passed-in CSID or UPN.
Argh, a step backwards in agreement. WAAY back in Montreal we agreed that
the authentication process could generate > 1 UPN for a set of
credentials. We never precluded that all of those UPNs must be unique for
a CU. If its not unique per CU then it in effect is a group UPN.
Im claiming that groups can be easily handled by this ability to have > 1
UPN generated when I AUTHENTICATE with the CS and that is something that
all CS vendors will have to deal with. Im NOT a big fan of bloating CAP
even more by having the CS act as a UPN directory server of sorts as it
just deters vendors from making CS implementations.
Just how do were you (collectively now) envissioning that the CS would use
the other UPNs that are generated as part of the certification process??
Are they to be ignored? If all CSs must generate the same list of UPNs
for a given set of credentials then what is the big deal in the CS using
them to evaluate VCARs, etc later one?
I think that in an effort to 'add groups' into CAP we are making this
issue overly complex. It is not that difficult for a CS to compare a list
of UPNs (for an authenticated CU) against those on VCARs instead of simply
comparing 1 UPN. Or am I missing some argument somewhere that says groups
have to be a complex beast??
>On first thought, this approach seems more complex, especially for the
>maybe, I just need to hear more...
Ok this may be bass ackwards but Ill try to rephrase my idea in as simple
terms as Im able at this time of day:
1: The AUTHENTICATion process may result in > 1 UPN being generated for a
given set of credentials and
2: Not all UPNs are 100% unique per CU
1: It is possible to have a 'group' UPN generated as one of a CUs UPNs
when they AUTHENTICATE and
2: A CS should be able to match ANY of the UPNs generated during
authentication in a normal UPN check (ie: in VCAR evaluation)
1: This 'group' UPN can be used anywhere a UPN is normally used (ie: VCAR)
2: No extra or overly complex extra mechanisms are needed in CAP to
distinguish a 'group' UPN from an 'non-group' UPN and
3: We do not need to distingush beteen 'group' and 'non-group' UPN flavors
Does this help clarify my original posting??
Bruce Kahn INet: Bruce_Kahn@xxxxxxxx
Iris Associates Phone: 978.392.5335
Westford, MA, USA 01886 FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...