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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Re: [xacml] Observation on J2SE context proposal (fwd)




---------- Forwarded message ----------
Date: Mon, 3 Jun 2002 09:46:03 -0400 (EDT)
From: Polar Humenn <polar@syr.edu>
To: Michiharu Kudoh <KUDO@jp.ibm.com>
Subject: Re: [xacml] Observation on J2SE context proposal


I also have some comments on the ContextPrincipal proposal.

At the very outset, I see that we are quickly going toward the notion of a
"ComplexPrincipal".

I would rather see ONE principal, and that principal be structured
appropriately by the way the security software (PEP?) sees the principal
that is the subject of the access decision request.

I can see the need of having multiple principals, i.e.  CodeSource and
Subject, etc. but these are not "principal types" they are "roles" played
by simple or complex principals.

The principal calculus denotes such things as "P as R", where P is a
(possibly complex) principal, and R is a role, (or a simple principal).

You may, for example, have principal Gates be the subject of the access
decision, however, he is running code signed by both Sun and Microsoft.

This complex principal would look like:

((Sun 'and' Microsoft) 'as' CodeSource) 'quotes' Gates)

So, instead of having a mismash of principals in the Context, of which the
policy engine must guess what is happening at the PEP, the security
software on the PEP prepares the request setting up the structured
princpal appropriately.

Also, for the record, and I will keep on saying this, as I have said
before, I believe that the "RequestingUser" or "Requestor" has the wrong
connotation in this situation. Formally, in the PDP context, the
"requestor" should be the thing asking the access decision question, which
has NOTHING to do with the "subject" of the access decision request. I
believe the actual "requestor" in this situation,(i.e. the PEP?), is out
of scope of the policy itself.

Cheers,
-Polar






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


Powered by eList eXpress LLC