OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Resource sets and resource string semantics


Even though I'm supposed to be able to read XML as if it were English :-), 
I find Evan's examples below *very* clear and easy to follow for discussion 
purposes.  It would be great it we could construct *one* storyboard (a 
real, concrete scenario) that has a need for every kind of assertion, and 
then use that storyboard to compare design proposals.

More comments below:

At 11:39 AM 5/15/01 -0700, Evan Prodromou wrote:
> >>>>> "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).

The two examples above seem to demonstrate that it's a bit misleading to 
stuff every kind of assertion into a subject/action/object 
framework.  Sure, SAML users could shoehorn everything into authZ 
attributes, but if we use nice clear markup in encoding our other 
assertions, it would be more attractive to use the specific assertion desired.

>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.

Indeed!  So perhaps this is a privacy reason that will discourage use of 
attributes for everything.

         Eve
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC