RE: Requirement for Isolated Request for Authorization Atributes

[Philip Hallam-Baker <pbaker@verisign.com>]

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.


Where it becomes important is when it is attached to applications, since it
is not Alice that is doing diddly squat, Alice is accessing the file in the
same sense that the Pharohes built pyramids and Hadrian built walls.

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 think this comes into the definition of the subject [aka the Principal].
At the moment we have a structure of the form:


<Subject>
   <Account>Alice</Account>
   <ds:KeyInfo> </ds:keyinfo> 

So we can identify Alice by either the account name (possibly a URI), or by
the crypto credentials by which she is to be identified (password, public
key etc.).

I would like to add in an attribute to express the concept of an active
role:

<Subject>
   <Account>Alice</Account>
   <Role>urn:dns-date:the-administrator-role-urn</Role>


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


Finally in discussions with Tim two different 'identity' issues came up:

1) How is the subject of the assertion to be authenticated?
	By holdership of the assertion - has been authenticated already
	By specified credentials
	By unspecified credentials

2) What identity is the transaction logged to / charged to etc?
	I.e. the account name

		Phill

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


> -----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.
> 
> > -----Original Message-----
> > From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> > Sent: Wednesday, March 14, 2001 7:07 PM
> > To: 'Security-Core (E-mail)
> > Subject: FW: Requirement for Isolated Request for Authorization
> > Atributes
> > 
> > 
> > [Darren asked me off list about the policy issue, so I 
> > responded, then I
> > thought that the response was probably worth forwarding to 
> > the whole list]
> > 
> > 
> > OK, so we are doing an XML standard and want to support multi-domain
> > assertions. This leads naturally to the use of URIs to 
> > represent resources.
> > 
> > So the file xyz.html is actually specified as 
> > file://machine.alice.test/directory/directory/xyz.html
> > 
> > 
> > We also have a clear need for what in VMS were called 'rights 
> > identifiers'
> > and some in the group are referring to as 'roles' (strictly 
> > speaking a role
> > used to mean a rights identifier that could be enabled and 
> > disabled at will
> > by an additional authentication step).
> > 
> > In XML space the natural expression for roles is to use a URN 
> > since they are
> > a pure name, they do not identify a specific resource:
> > 
> > URN:dns-date:irrelevant.test:2001-01-02:14.00.01:29482
> > URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==
> > 
> > In neither case can the URN be 'resolved' to a resource, the 
> > meaning of the
> > URN comes from its use. It is similar in concept to the 
> > xmlns="http://..."
> > line that appears in much XML. The label does not actually 
> > need to resolve,
> > the semantics are not necessarily obtained by resolving the 
> > URI. What is
> > important is only that there are never two semantics bound 
> to the same
> > label.
> > 
> > 
> > This approach naturally leads to the conclusion that the statement
> > Alice is authorized to access
> > file://machine.alice.test/directory/directory/xyz.html
> > 
> > is structurally the same as:
> > Alice is authorized with the rights identifier
> > URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==
> > 
> > In both cases the form is
> > <Subject> is authorized for <Resource>[URI Reference]
> > 
> > 
> > However the subject can also be usefully identified by a URI 
> > reference.
> > After all to disambiguate the account 'Alice', the natural 
> > approach would be
> > to add in her domain 'alice@nowhere.test'. Rather than tag 
> > this form for
> > disambiguity with XML I would rather push it down to the URI level
> > "mailto:alice@nowhere.test".
> > 
> > so what we get is 
> > <subject-URI> is authorized for <Resource-URI>
> > 
> > 
> > So what is the statement made by:
> > 
> > URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789== [our 
> > rights identifier
> > URN]
> > is authorized for
> > file://machine.alice.test/directory/directory/xyz.html
> > 
> > 
> > I think that the fact that the representation work well 
> > indicates that the
> > correct level of design consistency has been achieved. It 
> > would be possible
> > to 'design out' the expression of the policy statement but 
> this would
> > require considerable effort and result in a very rigid and 
> > limited scheme.
> > 
> > 
> > Now this is a policy statement but it is nothing like the type of
> > 'capability' or 'ACL' like structures that are traditionally 
> > associated with
> > 'policy'. What I believe we all want to avoid touching is a 
> > policy language
> > or stating that this is a problem SAML should commit to 
> > meeting requirements
> > for. If on the other hand there is a useful subset of the 
> > policy problem
> > that can be encoded in this fashion, that is OK.
> > 
> > 
> > 		Phill
> > 
> > Phillip Hallam-Baker
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> > 
> > 
> > 
> 
> ------------------------------------------------------------------
> 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