[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Resource sets and resource string semantics
I agree if you don't want attribute authorities to issue assertions across resource sets, you don't need the functionality of resource sets. In my original posting which started this thread I wrote: > > It occurs to me that some may feel that this sort of assertion should > be considered by XACML, rather than SAML. I guess one possible > resolution is to leave it to XACML. > I think we do need attribute authorities to issue assertions across sets of resources. I believe that will be an important use for SAML. I think not handling this in SAML severely and artifically limits the utility of SAML. I am really having trouble seeing why it should be excluded, but I know that that not everybody agrees with me. Nigel. > -----Original Message----- > From: Evan Prodromou [mailto:evan@outlook.net] > Sent: 15 May 2001 19:40 > Cc: security-services@lists.oasis-open.org > Subject: Re: Resource sets and resource string semantics > > > >>>>> "EN" == Edwards, Nigel <Nigel_Edwards@hp.com> writes: > > EN> I think it would be useful to allow Attribute Authorities to > EN> issue assertions containing strings of the form > EN> http://www.hp.com/* > > See, now, personally, I don't think we need to have any mention of > resources in authorization attribute assertions. Authorization > attributes, I believer, are about the *principal*, not about > resources. So... > > Employed-By=Outlook Technologies, Inc. > Role=Engineer > Group=Managers > > ...would all be authorization attributes of yours truly (pardon the > faky syntax). Meanwhile... > > Subject=Evan Prodromou > Action=Read > Object=http://www.hp.com/index.html > Is-Authorized=Yes > > ...would be an authorization decision (Object is a > resource). Something like... > > If (group Eq "Managers" And > (Role Eq "Engineer" Or Role Eq "Marketing")) > Then > Action Read > Object http://www.hp.com/* > Authorized > > ..would be a statement of *policy*. I guess what I'm trying to say is > that having a rich way of naming resources is valuable if you're > expressing authorization policy about resources, but otherwise it's > not too useful. > > Of course, there's nothing that would keep an attribute authority from > putting out something like this: > > Employed-By=Outlook Technologies, Inc. > Role=Engineer > Group=Managers > Authorized-To-Read=http://www.hp.com/* > > ...but I think that's probably a bad idea, security-wise. It doesn't > seem terribly prudent to put policy into attribute assertions, since > they're sent all over the place. Consider: > > Employed-By=Outlook Technologies, Inc. > Role=Engineer > Group=Managers > Authorized-To-Read=http://www.hp.com/* > > Not-Authorized-To-Read=http://www.outlook.net/plans-for-layoffs/ > > ...which gives a little too much info to other entities analyzing or > storing attribute assertions. > > ~ESP > > -- > Evan Prodromou <evan@outlook.net> > Applications Lead > Outlook Technologies, Inc. > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: > security-services-request@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC