[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UPN + GROUP + UPNEXPAND question.

At 10:53 AM 2/27/2000 -0800, Doug Royer wrote:

Within the context of groups, when do you get MULTIPLE UPNs?

I don't think you do. The UPNEXPAND examples show multiple CSIDs being returned but not multiple UPNs.

Section 2.4.3, User Groups, has a misleading paragraph:

   UGs are expanded as necessary by the CS. The CS MUST accept  a CUA
   request for UG expansion, although the CS may be configured to restrict
   some responses.  The CS MAY expand a UG (including nested UGs) to obtain
   a list of unique CUs.  Duplicate UPNs are filtered during expansion.
   Incomplete expansion should be treated as a failure.

At first I thought that "Duplicate UPNs are filtered during expansion." should be changed to "Duplicate CSIDs are filtered during expansion." Now I am not so sure. Maybe the UPNEXPAND examples are incorrect? Was the intent actually to allow a CU via a CUA determine what users were members of a user group?



There was talk that you MUST do a UPNEXPAND each time you
authenticate?

I must have misfiled some messages I can't find a message that indicates that anyone proposed this.

Seems a silly to have an extra round trip.

I agree.

Why not do it as part of the authentication reply?

I don't see why it should be needed as part the authentication reply either.

Then I still do NOT know what you do with them. At what point
does the CUA ever pass them back to the CS? If never, then
what's the point?

I don't think that a CUA would ever pass the result of UPNEXPAND back to the CS. That would seem to be going down the road of using CAP to administer groups which I thought was out of scope by consensus of the group.


Perhaps those of you that understand UPN's can send some text or
email describing when you get them? The current CAP draft and
the text from Paul (I think it was from Paul) does not seem to say.

A UPN is the result of authentication to the CS with the possibility of a few well understood transformations. Normally the user asserts their UPN offers sufficient proof to the CS that it is believed. Not that we would do this, but as an example: UPN=pbh@xxxxxxx PASSWORD=foo.

Or a certificate could be presented, verified, and the UPN read out of the certificate.

A SASL implementation could also authenticate the user, and present the authorization id as defined in the SASL RFC and the authorization id would be the UPN.

Finally after the initial authentication, the IDENTITY command could be used. I don't see the CS forcing the UPN upon the user. I don't see the CUA asserting a list of UPNs during a transaction to be subsequently used by other operations. (You may see a CUA putting a list of UPNs on the wire as part of a VCAR definition.)


I think Bruce says they comeback as part of the authentication reply?

That would be a misunderstanding. I must have said something the was confusing at some point and later it got asserted as fact. My apologies to Bruce.

Yet no one that proposed any new text has replied to that question.
And I can't find any text that says that.





There was no proposed changes to the ABNF or any text, or any example
in CAP-draft that shows when you get them, other than UPNEXPAND.

I don't think the draft needs to go into them any further, if everybody agrees with what I have said up to this point :)


As I understoon groups of calendars, it was meant to be something like:
If you happen (at run time) to be part of group-A, and there is
a calendar that has modify permission to cal-group-a, then you
can modify that calendar.


That's what I thought too.

So why does the CUA ever need to know
the UPN of group-A ? 'user' has or does not have permission
to modify cal-group-a. Why does the CUA care what the value
of the UPN property is that allowd that? Why can't it just
work, or you get permission denied?

I don't think the CUA cares :) I think someone thinks the user might care. :)

I may be confused but I think someone tried to sneak the equivalent of SMTP's EPN into CAP.


Would it be something like:

small modification below


C: AUTHENTICATE <user> <password> 

[ no in a username password case change the above to: ]
    C: AUTHENTICATE <UPN> <password>

   S: 2.0
   S: .
   S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   S: Content-Transfer-Encoding: 7bit
   S:
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/CAPserver//EN
   S: VERSION:2.1
   S: CAPVERSION=1.0
   S: ITIPVERSION=1.0
   S: AUTH=KERBEROS_V4
   S: AUTH=DIGEST_MD5
   S: CAR=CAR-FULL-1
   S: MINDATE=19700101T000000Z
   S: MAXDATE=20370201T000000Z

Remember that you actually connect as part of CAP, but the time that we use AUTHENTICATE we actually dive into SASL, which possibly takes us into other transactions over the wire, then we pop back into CAP. The normal C: S: .... notation doesn't really accurately reflect what might be going on. Treat SASL as a bit of black box.

Does this help?

Paul