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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: Re: Entitlements and PDP vs PEP Separation



Phill, 

I pretty much agree with this. I also think its worthwhile defining a few 
Attribute's that are mandatory to implement, so's there's a bit more than 
just the Decision element which has multi-vendor interop.

Usual suspects would be identity (with application qualifier), groups,
roles... kind of like in the PKIX AC profile.

However, I'm not sure we really need an interoperable Capability defined for
the PDP response message. I'd leave that one as a vendor specific extension.

Stephen.

> Philip Hallam-Baker wrote:
> 
> In XKMS there is a request tag <Respond> which allows the elements to be returned in the response
> to be specified.
> 
> We could have a <Respond> tag with options such as "Decision" "Attribute" "Capability" etc.
> 
> This would allow the SAML spec to be model neutral, allowing the end users authorization model to
> be supported rather than insisting on the one we agree to for design purposes.
> 
>         Phill
> 
> 
> Phillip Hallam-Baker
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
> 
>      -----Original Message-----
>      From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
>      Sent: Wednesday, March 28, 2001 10:54 AM
>      To: 'Ken Yagen'; security-services@lists.oasis-open.org
>      Subject: RE: Entitlements and PDP vs PEP Separation
> 
>      In my view, the issue of PDP vs. PEP is a question of definition. A PEP has no
>      non-volatle, administratable policy store. It bases its actions on the decisions of the
>      PDP. There is no reason PDPs cannot be tiered and contribute bits of policy to the
>      decision, however eventually we get to a component which enforces the decision.
> 
>      At the other end of the scale, the PDP and PEP may be closely coupled, as in our
>      product. However, SAML wishes to discuss the possibility of PDPs emitting assertions,
>      therefore we must consider these as distinct architectural entities.
> 
>      As Bob Blakely pointed out to me back in December, once an Authority emits an Assertion,
>      there is no way of preventing a Relying Party from applying a policy to it. However, I
>      think the design should reflect its intended use.
> 
>      Your example can be addressed in serveral ways, one of them is to closely couple the PEP
>      and PDP. In this case there is no need to define a standardized way of communicating
>      this information.
> 
>      I think some people believe that SAML might potentially be so ubiquitious that it would
>      be imbeded in simple devices like moble phones or toasters. If this is the case, the
>      rules for a PEP will have to be very simple.
> 
>      Hal
> 
>           -----Original Message-----
>           From: Ken Yagen [mailto:kyagen@crosslogix.com]
>           Sent: Friday, March 23, 2001 6:39 PM
>           To: security-services@lists.oasis-open.org
>           Subject: Entitlements and PDP vs PEP Separation
> 
>           I wanted to comment on the discussion during the last TC regarding
>           entitlements and this issue:
>           >decision point evaluates policy and makes a decision, and an enforcement
>           >point applies the decision.
> 
>           In real world applications, the separation is not so cut and tried. Consider
>           this policy:
>           "Analysts can view research reports if the report is in their geographical
>           territory and they report represents an industry the analyst covers."
> 
>           In this example, Joe, the user, is an analyst that covers the Oil Industry in
>           the United States. How do you enforce this policy if the user is requesting a
>           list of research reports he can view? If the PDP evaluates policy and the PEP
>           enforces the yes/no decision, you might have to iterate through a database of
>           thousands (or possibly millions) of reports and check with the PDP for each
>           one to decide if the user can access it. This can be a very time consuming and
>           inefficient process.
> 
>           On the otherhand, what if the PDP, instead of returning yes/no, returned this:
> 
>           PEP -> Can Joe view research reports?
>           PDP -> Yes, Joe can view research reports that meet these criteria:
>           industry=Oil, region=US
>           The criteria could then be passed to a database query (or something else) to
>           retrieve the correct reports. The decision has been made by the PDP but
>           enforcing requires more than just granting or denying an action.
> 
>           Any solution that attempts to address entitlements needs to support this type
>           of scenario.
> 
>           Ken Yagen
>           Director, Software Development
>           CrossLogix, Inc.
>           http://www.crosslogix.com
> 
>           -----Original Message-----
>           From: Eve L. Maler [mailto:eve.maler@east.sun.com]
>           Sent: Friday, March 23, 2001 12:38 PM
>           To: security-services@lists.oasis-open.org
>           Subject: RE: The Hal/David model
> 
>           And to follow up on one of Darren's points and bring things around to our
>           most recent TC discussion...
> 
>           At 11:46 AM 3/23/01 -0800, Darren Platt wrote:
>           >...
>           >I believe a statement such as such as "user 'noddles' is granted 'execute'
>           >on '/usr/bin/guitar'" is a statement of policy.  This statement is not that
>           >different from "users who are 6 feet tall are granted 'execute' on
>           >'/usr/bin/guitar'" or "users who have the role 'musician' are granted
>           >'execute' on '/usr/bin/guitar'".  These latter two are clearly require a
>           >'decision' to enforce and are therefore the input of the policy decision
>           >point.  I therefore don't think that this is something a PDP would pass to a
>           >PEP, rather something a PDP might pass to another PDP.  By their names, PDPs
>           >and PEPs seem to me to be abstractions based on their functionality - so a
>           >decision point evaluates policy and makes a decision, and an enforcement
>           >point applies the decision.
> 
>           So, to simplify the logical perspective even more:
> 
>           decision PDP(policies, attributes)
>           permission PEP(decision)
> 
>           ?
> 
>                    Eve
>           --
>           Eve Maler                                             +1 781 442 3190
>           Sun Microsystems XML Technology Development  eve.maler @ east.sun.com
> 
>           ------------------------------------------------------------------
>           To unsubscribe from this elist send a message with the single word
>           "unsubscribe" in the body to: security-services-request@lists.oasis-open.org

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


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


Powered by eList eXpress LLC