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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

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


Subject: RE: Requirement for Isolated Request for Authorization Atributes


I agree that the question of *which* roles needs to be left to the
application.

However I do think we need to allow a distinction to be made in the error
returns between 'you are not allowed access to this resource' and 'you are
not allowed access to this resouce in your currently active roles'

Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


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

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC