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