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] | [List Home]


Subject: RE: XACML InterOp at Burton Catalyst - scenario document update for review and meeting plans


Ok, let’s set a call for every Thursday at 11, starting April 26. That will be simpler to remember.

 

We can use the XACML bridge:

 

Tel: 512-225-3050 Access Code: 65998

 

Hal

 


From: Rich Levinson [mailto:rich.levinson@oracle.com]
Sent: Wednesday, April 18, 2007 5:46 PM
To: xacml-demo-tech@lists.oasis-open.org
Cc: Denis Pilipchuk; dee.schur@oasis-open.org; staff@lists.oasis-open.org; ggebel@burtongroup.com; Hal Lockhart; prateek.mishra@oracle.com; miken@burtongroup.com; xacml@lists.oasis-open.org; xacml-demo-mktg@oasis-open.org; brynn.mow@jerichosystems.com; Andrew.Rappaport@ca.com; sconvery@idengines.com; foster@mcs.anl.gov; carl@isi.edu; sampo@symlabs.com; mark.oneill@vordel.com; kjk@internet2.edu; aclark@novell.com; sacha.labourey@jboss.com; mark.little@jboss.com; tim.moses@entrust.com; jishnu@hp.com; susie@symlabs.com; jeff@symlabs.com
Subject: XACML InterOp at Burton Catalyst - scenario document update for review and meeting plans

 

Hello All,

In order to get things moving toward a successful XACML Interop, I am
sending out an update to the XACML 2.0 Scenarios document.

This document should be considered totally "working", nothing is cast in
concrete at this time, and, in particular, there are several issues that
probably need to be discussed before we can get to the precise details
of each scenario and attribute involved. As such it only addresses some
of the items raised by Denis in the earlier email from 3/23 which is
included below. (Note also: that as I was working
the use cases, a lot of questions started to emerge, and rather than try
to answer them myself, I figured this is probably one for the group and
a reasonable place to start.)

The biggest change to the document is section 2.1 Use Cases including
sections 2.1.1 and 2.1.2. The scenarios are unchanged at this time. You
may turn on the highlight change bars to see diffs from previous version.

Among the several rather straight-forward issues, there is one significant
issue that probably requires discussion and agreement on how it will be
approached. This is the gathering of attributes in the Authorization use case,
and the possible setting of attributes in the Policy Exchange use case.

Input from any and all participants is strongly encouraged. Particularly,
this version of the document is intended to weed out the paths that we
are going to ignore and firm up the paths we are going to Interop. The
diagrams in sections 2.1.1 and 2.1.2 should be considered weed patches
from which we will, as a group, try to cultivate a garden.

I suggest that we have weekly meetings between now and the Interop. One
possibility that comes to mind is Thu 10 AM, which is the time of the regularly
scheduled bi-weekly TC meeting and when there is a meeting, we can have
a conference directly after, say at 11 AM, and when there is no TC we could
meet at 10 AM. Or to keep it simple we could just meet at 11 AM every Thu.
Volunteers to set up conf bridges etc are strongly encouraged. There is no
TC mtg tomorrow so 10 or 11 tomorrow is a possible kickoff or we could
wait until next week and use this week to exchange emails.

Please let Dee know if anyone is missing from the distr list. Future memos
will just go to xacml-demo-tech.

At the first meeting we can decide who is doing what in terms of responsibilities, etc.
I am assuming Hal is the coordinator. This memo and attached doc is to try to keep
things moving so participants at least have a context to which they can relate any
current concerns and that we can capitalize on the work that has already been done.

    Thanks,
    Rich Levinson


Rich Levinson wrote:

Hi Denis,

Thanks for the great feedback. I think we are pretty much on
the same page. Comments inline (note: pardon the verbosity of my
replies, it is more to float out additional context to be considered and
discussed, in addition to replying directly to your points, which I think
are all legitimate):

(Also, if others on the list would like to add something in, please feel
free to do so as I will try to incorporate all contributions to the
document that there is general agreement on)

    Thanks,
    Rich

Denis Pilipchuk wrote:

Dear Rich,

 

Thanks a lot for coming up with this initial set. Here're my thoughts on the document and the described scenarios:

 

General document thoughts:

 

I’d like to state somewhere in the introduction section of the document that we separate the issues of settling on the details of exchange protocol/policy (which should be specified very precisely), and UI representation. They are really orthogonal, and each participating vendor should be able to decide, how much work they’d like to invest into putting together a sample PEP App (i.e. stock brokerage). Complexity here may range from a single static page with couple of entry boxes and buttons in the most primitive case case, to a rich interactive Web application.

I agree. In fact, when I started doing the use cases and was mulling "use cases" vs "scenarios", I decided
that the "use cases" would come first and be used to describe the actual messages exchanged etc., particularly
in the xacml arena, between the PEP-CH-PDP-repos-PAP, and that the "scenarios" would be last as
basically any application that one could envision that could drive the underlying message exchanges.
So, I will add something up front to elaborate on this strategy so participants can recognize that right up front.
I agree they are "orthogonal", in particular, it is handy to view the client-svc exchange as "horizontal" from
left to right with an intercepting PEP: cli-PEP-svc. The PEP then is the top of the vertical xacml exchange,
where it is the PEP's job to pull stuff from the horizontal data flows and stuff it down the pipe for the az req.


The vendors should be free to develop and use a joint test application, if so desired. I.e. I’m proposing making development of the PEP part optional, as long as a vendor teams up with somebody else to present a working PEP – this way, we’ll have at least one working test application J It goes w/o saying that each vendor would have to have a XACML PDP and/or XACML policy import/export facility as a pre-condition of participation in the interop event.

This is a very good idea. That will further break apart the cover appl from the xacml
aspects of things and allow dev people to focus on the technical aspects of interoperability,
while the mkt folks can work to dress up the appl-oriented presentations. And in particular,
it will allow each vendor to put together their own substitute front or back end if they
don't like the minimalist common client and server pieces that can be used for driving
testing the internals. Now all we need is a volunteer to write the shared minimalist test
pieces! But that shouldn't be too hard, since everyone is going to have to have "something"
that is driving their tests before they get to attempt interoperability.

 

Authorization Decision scenarios:

 

Section 1.1, last paragraph: we need to better separate actions from attributes. Credit limit and types of trades are definitely attributes, threshold – I doubt it, it’s rather a policy item, blocking access or assigning new managers I view as purely actions, checked and executed from PEP

I assume the section numbers here are from the scenarios section, which is 2.2 in the parent doc,
but 1.1 in the initial excerpt I sent out.
One assumption I was making here was that the "account" is a stateful business object (although
for canned test scenarios it could be in a frozen state).
Therefore, all values about the account would come from the account. Therefore, depending on
the technology implementing the scenario this could be done in a number of ways:

    A PEP-oriented brute force way might be to haul the whole account structure out of the web
    service and put it in an xml document and send it down as part of the xacml-context:Request in
    the ResourceContent which is kindof the type of thing going on in the XACML 2.0 Core
    spec example 2 - lines 1050-1059 (a174-a181).

    At the other extreme, one could imagine a minimal xacml-context:Request, only containing the
    Subject info and minimal resource and action info, but the ContextHandler at the PDP would
    be called into action to use a PIP to get what it needed from the account.

The reason I used the cover term "account restrictions" was to kind of be one level above the
distinctions between what's an attr, what's a threshold etc. In particular, a "restriction" can be
thought of as the account-side setting of an attribute against which current account activity
can be measured. So, for example, if the account "credit-limit" is $10,000, and the customer has
one trade already that hasn't been settled for $7,500, and a requested trade value of $5,000,
then the policy would say something like (in plain langauge - to be translated to xacml syntax):

    if  (unsettled-balance + requested-trade-value > credit-limit) then deny

One way or another, these 3 attributes and their current values need to be provided
to the pdp for evaluation.

As far as I can tell, this is much like the sample appl in the xacml 2.0 spec, where everything
is in the patient-record from patient's name and addr, doctor attending, treatments given etc.
(section 4.2.1). Also, all the rules are pretty much dependent on comparing data from the
patient record to the subject attrs etc.

I think, in general, that every account would be tailored to the customer and have threshold
data such as allowable credit limit, stored as an account attribute.

I am not sure I understand how you are using the term "action". Basically, a xacml Action is
a category of Request data, which includes Subject, Resource, Action, and Environment,
all of which have child xacml-context:Attribute elements. All of these are collected by the PEP
or the CH and auxiliary PIP and fed to the PDP.

Possibly you are looking for emphasis on the "Action" associated with each scenario, which I
agree should be made more explicit in the 4 concrete scenarios, all of which identify it in step 1,
but don't really focus on it: In sections 1.1.1.2 (2.2.1.2) and 1.1.1.4 (2.2.1.4) it should be
apparent that "operation" is the action which has values "purchase" and "approval" respectively.
In 1.1.1.1 (2.2.1.1) and 1.1.1.3 (2.2.1.3) both of these are the initial "access" or (action = read)
request, which must be granted before access is allowed to any account data or actions. This
is the 2-level aspect of this model with the first level being authorized to access the account
at all, and the second level being the fine-grained access to specific actions on the account.

Section 1.1, last paragraph, trading thresholds: since embedding security logic into applications is a bad security practice in general, and to demonstrate the power and flexibility of the XACML language, I’d like to suggest handling trading thresholds via policies, and just returning obligations to the PEP specifying whether approval is required or not

I agree that the whole point of xacml and fine grained authorization is to extract the authorization
logic out of the business objects and into the policy. Every attempt is being made in the description
of these scenarios to have all policy-oriented data as attributes that are simply pulled from the
business object and delivered to the PDP for evaluation in policy context. At the same time, we
don't want to burden the policies with a whole bunch of application specific data that it needs to
store somewhere, so, imo, data like thresholds, which in general are account-specific, should be
stored with the acct, but only accessible for read and write by appropriate actors.

Section 1.1.1.1: I don’t think the authentication part should be handled by the document – instead, I’d limit this part to just “view account” action and leave all username/password details out of the scope. Any exchange between PEP and PDP assumes already authenticated user, passing a subject token which we’ll agree on

I agree with you there. The password should have been handled prior to the scenario, similar to
section 1.1.1.3 (2.2.1.3) where the acct mgr doing the same type of access operation, but in
a different subject domain specific role (i.e. we would define an application vocabulary "role"
such as the xacml core application-specific role defined in lines 1038-1042 (a166-a168)) was
explicitly identified as being "already logged in" with an associated Identity object. The customer
in scenario 1 should arrive in this same state of having Identity already established as well.

 

Additionally, in order to limit the scope of the application, I’d like to suggest having just 3 customer-based scenarios (view, purchase, trade) for the Authorization Decision, and move all management operations (manager access, manager approval, account management) for both managers and VPs to the Policy Import/Export set of scenarios. This will provide a clean and understandable separation of the applications in case somebody will participate in one scenario but not in another.

I also think this is an excellent idea, however, I think we need to make a distinction
between management operations which change account values for restriction purposes,
which can all be done while leaving the existing policies in place, vs changing the actual
policies themselves. In fact, I think the next round of analysis on this, where we start
to define actual policies will bring out this distinction, which I think is of value to present
to the Interop audience. i.e. imo, enterprise security organizations probably don't want to
be changing policies a lot, as that will make it very difficult to enterprise mgmt to be
able to conceptualize what the company policies actually are. It is much
easier to change a value that a policy expression evaluates than to change the policy
expression itself.

    Thanks again,
    Rich

 

Regards,

Denis

_______________________________________________

Denis Pilipchuk
AquaLogic Enterprise Security group, BEA
Phone: 781-993-7232
denis.pilipchuk@bea.com
 

 

 

Hello Everyone from today's conference call,

As agreed at end of meeting attached is parent document from which
the scenarios with the invitation were extracted.

Also below is the cover email that went out with the original version
of the document with scenarios.

    Thanks,
    Rich Levinson
    Oracle



-------- Original Message --------

Subject:

Re: [xacml-demo-tech] Burton XACML InterOp

Date:

Tue, 20 Mar 2007 10:38:30 -0400

From:

Rich Levinson <rich.levinson@oracle.com>

To:

Dee Schur <dee.schur@oasis-open.org>

CC:

xacml-demo-tech@lists.oasis-open.org, xacml@lists.oasis-open.org, 'Scott McGrath' <scott.mcgrath@oasis-open.org>

References:

<E1HRyjn-00066P-Rx@ms01.oasis-open.org>

 

All,
 
Attached is a first draft of the proposed sample scenarios. It is
intended for discussion. It is a very flexible concept: a managed
brokerage account, where the customer can do stock trades
in coordination with an account manager. This is the kind of
thing one might find in high value accounts where the customer
as well as the brokerage coordinate their efforts to meet the
objectives.
 
At the same time it is based around a simple core structure of
3 levels of user: customer, acct manager, vice president. It is
intended that there be 2 accts, so one can see that certain parties
have access to one the other or both.
 
Also, there are approvals involved, so one can easily see workflow
being integrated if desired.
 
By nature it is very extensible and one could extend it to have
partners involved such as a bank for bank transfers, a trading
service to execute trades, etc.
 
Again, the intent is to get a sample appl out there which can provide
a context for doing an interesting Interop. The actual appl can be
quite minimal, only supporting the key attributes that are involved
in the scenarios or dressed up for other purposes.
 
Finally, only the Authorization portion has been done with a couple
simple scenarios to give the flavor of the demo.
 
The xacml-demo-tech group can discuss exactly where we want
to head with this and it is intended only to be a starting point.
 
    Thanks,
    Rich
 
Dee Schur wrote:
 
 
 
 
-------- Original Message --------

Subject:

[xacml] Burton XACML InterOp

Date:

Thu, 15 Mar 2007 18:47:08 -0500

From:

Dee Schur <dee.schur@oasis-open.org>

To:

<xacml-demo-tech@lists.oasis-open.org>, <xacml@lists.oasis-open.org>

CC:

'Scott McGrath' <scott.mcgrath@oasis-open.org>

 

 
> Hi,
> We just got off of a call with Burton and they once again, emphasized the
> tremendous need for interoperability and the use of XACML. They are
> confident that if we do it right, we will have a tremendous amount of
> interest based on their customer feedback, and this is a very exciting
> opportunity! 
> Prateek and Richard are working on the type of scenario that Burton would
> like to see, more aggressive and compelling than the one we have developed
> so far.
> Also, they would like to see more participants. I will be doing a lot of
> outreach in the next few days as Gerry mentioned many vendors that have
> XACML embedded in their products but are not active in the TC. I would
> invite your help here. If you know of other players in this space, please
> shoot me an email with contact information ASAP. 
> If you are 'sitting on the fence,' and you would like me to speak with your
> marketing contact to assure then of the value of participation, please let
> me know. Burton has been very good to OASIS and they believe in our mission.
> Their customer clamor volume for interoperability continues to increase. 
> Best regards,
> Dee Schur
> 
>   



dee.schur@oasis-open.org wrote:

Invitation: Call to discuss XACML InterOp at Burton Catalyst
 
 -- Mrs. Dee Schur
 
 
Call to discuss XACML InterOp at Burton Catalyst has been added by Mrs. Dee Schur
 
Date:  Wednesday, 21 March 2007
Time:  05:30pm - 06:30pm ET
 
Event Description:
Conference Call Information:
 
5:30PM EDT, 3:30 PM MT, 2:30 PM Pacific
 
PHONE:  +1-319-643-7750
 
GUEST: 857415# 
 
Agenda:
This call is designed to discuss the XACML InterOp opportunity for all potential participants at the Burton Catalyst Conference in late June. 
 
Minutes:
 
 
View event details:
http://www.oasis-open.org/apps/org/workgroup/staff/event.php?event_id=14763
 
PLEASE NOTE:  If the above link does not work for you, your email
application may be breaking the link into two pieces.  You may be able to
copy and paste the entire link address into the address field of your web
browser.
 
  
 
 
 



 
 
 
BEGIN:VCALENDAR
METHOD:PUBLISH
VERSION:2.0
PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
X-WR-CALNAME:My Calendar
BEGIN:VEVENT
CATEGORIES:MEETING
STATUS:TENTATIVE
DTSTAMP:20070320T000000Z
DTSTART:20070321T213000Z
DTEND:20070321T223000Z
SEQUENCE:0
SUMMARY:Call to discuss XACML InterOp at Burton Catalyst
DESCRIPTION:Conference Call Information:\n\n5:30PM EDT\, 3:30 PM MT\, 2:30 PM
  Pacific\n\nPHONE:  +1-319-643-7750\n\nGUEST: 857415#\n\nGroup:
  Staff\nCreator: Mrs. Dee Schur
URL:http://www.oasis-open.org/apps/org/workgroup/staff/event.php?event_id=14763
UID:http://www.oasis-open.org/apps/org/workgroup/staff/event.php?event_id=14763
END:VEVENT
END:VCALENDAR


Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.



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