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

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

In conclusion this is an aspect of SAML usability, as is scoping who can
what roles and assertions, which is what I was worrying about in my last 


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

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

Powered by eList eXpress LLC