RE: Resource sets and resource string semantics

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

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
>