The first is what you are looking at, that is how to allow for an RP to act as a delegate of the original user. The second is how to allow user 1 to act as a delegate of user 2. The second is the one that I am more interested in at the moment.
However looking at the first case there are some questions that I think are interesting. 1. Should the fact that a delegation is occurring - and perhaps what delegation is occurring - be something that the user should be able to see and thus be a candidate for channel bindings? 2. At what point will the RP know that a delegation operation is needed. I think that there may be many cases where this is not known at the start as noted in your last message. It is also possible that different delegation statements may be needed to talk to different entities. What RP2 and RP3 will accept may not be quite the same SAML statements. Thus it is possible that multiple delegation statements may be required. 3. The delegated SAML statement is quite probably not going to be the same as the SAML statement about the subject. The set of attributes may be restricted in several different ways. I think that this means that there may be a requirement for a request of a delegated SAML statement that would be independent of a request for a new SAML statement with additional attributes. I believe that the second is doable through Josh's draft but the first has no standardization at all. 4. I would be very reluctant to standardize asking for delegation as a Radius attribute. That being said I don't see any reason that Moonshot could not do it internally. 5. For Moonshot - how much of the delegation can be done via Kerberos rather than SAML? Back to my issue. Part of what I need can be done via configuration, but I am not sure that all of it can be. I can think of cases where a delegation SAML statement is going to be required and as there is no standardized way of asking for one it is going to be problematic until that is developed. What can be done with active directory currently is done via either RP delegation or configuration work on the resource. Exchange has this complex system of marking who a mailbox owner is and who else can play in the mailbox and then turning that information into RFC822 header information that almost nobody can follow. This means that in many cases the necessary information can be put into either attributes in the original message (Bob is Alice's executive assistant) and then the enforcement policies can be directly written to deal with looking for all of the different types of roles that people can be playing and who they are playing for. The think I don't like about this is that somebody doing a temp placement needs to have a different type of role and a different set of rules. This makes the configuration half hard no matter what you do. Jim > -----Original Message----- > From: Sam Hartman [mailto:[email protected]] > Sent: Friday, April 20, 2012 8:42 AM > To: Jim Schaad > Cc: [email protected] > Subject: Re: [abfab] Delegation > > > We've started some discussions of delegation in the moonshot project as > well. > > We're focusing more on the RP side of it. That is, how an RP obtains a > credential to act as a delegated user, rather than the question of how we > indicate to a down-stream RP that delegation has occurred. > > we were thinking of providing a RADIUS attribute for an RP to ask for a > delegation credential. If that is supplied in an access-request then an > IDP/AAA server MAY supply a credential and key in an access-accept. > That credential could be used as an EAP credential (say with some PSK > method--possibly TEAP with a PSK cipher) to attempt to act as a user. > Then the IDP would be in a position to decide whether the delegation is > permitted. > > > This covers as much of delegation as AD gives you today. > It does not have a rich conversation between the user and IDP about what > delegation is required; for that you'd need to involve EMU in some way. > > Also, note that this is a form of cross-domain delegation. Within in a resource > domain, I think it makes more sense for the RP to end up with a Kerberos > ticket (in many cases at least). > > Just letting you know some thoughts going on elsewhere. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
