RE: Requirement for Isolated Request for Authorization Atributes

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

> 
> Phill wrote: 
> I agree that the question of *which* roles needs to be left to the
> application.

I agree with this too.

> Ken Yagen wrote:
> It's pretty common to want additional information along with an access
> denial. It may be you are not allowed access in this role or it may be
> you are not allowed access because your account balance is too low or
> something else. This is similar to another example I gave on the main
> list of "Yes, Joe can view research reports that meet these criteria:
> industry=Oil, region=US"
> 
> Whether this is the domain of XACML or SAML, I'm not really sure. SAML
> should just be flexible enough to support an authorization decision
> that contains more than a yes/no decision.
> 

I also agree with the above. In January, I tabled the following to the
use-case and core-assertions list.e.g. see:
http://lists.oasis-open.org/archives/security-core/200101/msg00001.html

> Nigel wrote:
> [R-AuthzDecisionRefused]
> Metadata should be provided for denied requests.
> If a request for authorization is denied, optionally metadata indicating
why
> the request is denied should be returned. 

I am not sure what the status of the above requirement is, but from
this thread it seems like there is general support for it.

Nigel.

> > -----Original Message-----
> > From: Darren Platt [mailto:dplatt@securant.com]
> > Sent: Friday, March 23, 2001 2:47 PM
> > To: Edwards, Nigel; 'Philip Hallam-Baker'; 'Security-Core (E-mail)
> > Subject: RE: Requirement for Isolated Request for Authorization
> > Atributes
> > 
> > 
> > Nigel and Phill,
> > 
> > Couldn't we leave the decision of which roles to assert for a 
> > principal up
> > to the implementation?  Wouldn't that be the responsibliy of 
> > the attribute
> > authority to know which credential to issue for the user?  
> > Otherwise aren't
> > we back to the 'credential negociation' problem that I 
> > thought we'd left out
> > of scope?
> > 
> > As far as scoping who can issue roles and assertions, isn't 
> > that up to the
> > administrative policy within the security domain, and 
> > therefore something we
> > should not specify here?
> > 
> > Regards,
> > 
> > Darren
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
> > > Sent: Thursday, March 15, 2001 4:05 PM
> > > To: 'Philip Hallam-Baker'; 'Security-Core (E-mail)
> > > Subject: RE: Requirement for Isolated Request for Authorization
> > > Atributes
> > >
> > >
> > > Hi Phill,
> > >
> > > >
> > > > One thing I am confused on, which is probably due to 
> > having learnt the
> > > > nomenclature in a different environment is what people are
> > > > defining as a
> > > > role.
> > > >
> > > > We are talking about an 'administrator role'
> > > >
> > > > Is this
> > > > 1) An attribute that is attached to Alice, so Alice has admin
> > > > privillege and
> > > > can access the admin type objects. Bob and doug also have
> > > > that privillege.
> > > >
> > > > 2) An attribute attached to a specialization of the Alice
> > > > account, a role
> > > > that Alice can enable and disable.
> > > >
> > > > We appear to be talking about (1), I think that (2) also 
> > needs to be
> > > > considered.
> > >
> > > I believe we were talking about 1.
> > >
> > > To build a usable system, 2 needs to be given some thought. 
> > Otherwise you
> > > have little choice but to enable all your power, all the time. To me
> > > this is an issue of being able to manage your assertions and
> > > authorizations.
> > > I am not sure SAML can do anything to help directly. I have 
> > discussed this
> > > more below in the context of your examples.
> > >
> > > > Specifically I want to be able to configure my email 
> > address book web
> > > > service so that I am authorized to read it, however when my
> > > > email program
> > > > spawns off an application (from a virus) that application
> > > > should not be
> > > > authorized to read the address book, initiate messages,
> > > > delete files etc.
> > > >
> > >
> > > I have worked on MLS unix systems in which the power of root was
> > > broken into 50 or so privileges. The concept of "least-privilege"
> > > says an entity should only be given the minimum privilege set it
> > > needs to do its work. So before you fork your application you
> > > drop all but the privileges it needs. Unfortunately, figuring
> > > out the minimum set is hard - there is no way to automate it
> > > (that I know of). This is one of the things that makes development
> > > on such systems challenging.
> > >
> > >
> > > >
> > > > Although I gave an example from email virus stuff I think
> > > > that the concept
> > > > would transfer to business very directly. Say Alice was a
> > > > manager with a $12
> > > > million signing authority. She might not want to activate
> > > > that authority to
> > > > the full extent each day she logged in, just in case one of
> > > > the employees
> > > > came by and ordered a Learjet when she left her terminal
> > > > unattended, on the
> > > > other hand she might not be that paranoid about people
> > > > ordering paperclips
> > > > from Staples.
> > > >
> > > >
> > > > When I used to manage VMS systems you would often see folk
> > > > with multiple
> > > > accounts, HALLAM & SYS_HALLAM for the user mode and system
> > > > administrator
> > > > mode. This works but it is clunky, it is very easy to end up
> > > > editing normal
> > > > files and finding you have to log into your system account to
> > > > read them. The
> > > > UNIX SU concept is better in this regard, but nowhere near
> > > > fine grained
> > > > enough (peon mode or armed with tactical nuclear device 
> > mode, take yer
> > > > pick).
> > > >
> > >
> > > If we believe (which I do) that you can't depend on hiding 
> > assertions
> > > for your security. The only way I can think of doing this 
> > is for an entity
> > > to have multiple principle identities. Powerful identities would
> > > be enabled
> > > (authenticated) only rarely: key material could be stored 
> > in separate key
> > > stores.
> > > As you point out, this kind of thing is somewhat clunky. Alice would
> > > presumably have
> > > her $12M key in a smart card, only rarely would that smart 
> > card be plugged
> > > into any
> > > system.
> > >
> > > In conclusion this is an aspect of SAML usability, as is 
> > scoping who can
> > > issue
> > > what roles and assertions, which is what I was worrying 
> > about in my last
> > > message.
> > >
> > > Nigel.
> > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
> > > > > Sent: Thursday, March 15, 2001 10:29 AM
> > > > > To: 'Philip Hallam-Baker'; 'Security-Core (E-mail)
> > > > > Subject: RE: Requirement for Isolated Request for Authorization
> > > > > Atributes
> > > > >
> > > > >
> > > > > Using URI's to denote roles is an interesting idea and 
> > seems to fit.
> > > > >
> > > > > One of the issues that needs to be considered to build a
> > > > usable system
> > > > > is how to scope the trust in an issuer (of role or 
> > other assertion).
> > > > >
> > > > > Folks might wisely trust Phill, but not Nigel to issue 
> > role/right
> > > > > URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==
> > > > >
> > > > > Thus some of the policy information a relying party will
> > > > need to have
> > > > > is who to trust for what. That requires a way if 
> > identifying issuers
> > > > > and scoping what they can issue: sets of roles and resources.
> > > > >
> > > > > I think some/most will say that the structure of this 
> > information
> > > > > is out of scope for SAML. However, if we don't give some thought
> > > > > as to how this might work, we could end with very complicated
> > > > > configuration issues at each relying party. (From previous
> > > > experience
> > > > > I believe that if we do SAML right, we will be able to use
> > > > > SAML structures
> > > > > to define this information, even though it is not an 
> > explicit goal.)
> > > > >
> > > > > Nigel.
> > > > >
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: 
> > security-core-request@lists.oasis-open.org
> > >
> > 
>