Dear Rich,
Thank you for pushing this forward, below are my initial comments to the
updated version of the document. As for establishing a weekly conf call
- I think this is a good idea, it's really needed at this point.
Thursday 11.00 EST sounds fine to me, but next week most likely I won't
be able to make it :-(
Before delving into details, I'd like to explain the primary unifying
theme for my comments below: the very first priority for me is
conducting a successful interop without requiring each participant to
create what'd amount to a new product release; IMO, the best way to
achieve this goal would be keeping the interop scenarios relatively
simple and well-defined. Additionally, while recognizing the business
value of this event, I'd prefer to start with simple (although possible
not so flashy) design, and add more meat as optional components, if we
have time toward the end. In other words, choosing between business and
technical requirements, my preference would be to satisfy technical
requirements first, and then seeing how we can add business value.
I agree with the proposal to define the use cases first; following that
I see us tackling specific scenarios and reaching an agreement on test
application(s).
Specific document comments:
Section 2.1.1
- line 129 - while this section lists 2 options for passing
XACML requests, I'd suggest using the scenario from the lines 130-134
(i.e. direct request/response) as the minimalist case. Interop based on
the SAML 2.0 profile (lines 135-137) can be added later on as an
optional step as a business value-add option, as it introduces
additional complexity to the testing.
- lines 143-146 - I'd add a subsection placeholder to Section 1
(or a new top-level section) for development of client applications; I'd
rather move text from these lines to a separate section, as it's related
to how we are going to define client test app(s).
- lines 147-148 - I'd also place them in the client test app
section (see above); conceptually - there'll be an authentication
service, but in practice, I see little value in formalizing this; the
implementation can be as simple as a JSP page with several
radio-buttons, defining sets of hardcoded user credentials to be sent to
the PEP
- lines 151-152 - I'd second this suggestion to deliver
identity attributes delivered with the request; fine-grained
authorization can be demonstrated by retrieving resource attributes; I
see no gain, just added complexity if requiring demonstration of the
identity attribute retrieval as well
- lines 155-157 - since the authZ request scenario will be used
separately from the policy exchange scenario, we'll need to define a set
of common policies for the appropriate scenarios; common in terms of
expected behaviour and responses, not policy format, which will be
different for each participating vendor
- lines 158-161 - I think it makes sense to demonstrate both
coarse and fine-grained cases; I'd like to suggest the following general
approach to attribute retrieval: identity attributes are always passed
with the request; resource attributes are always retrieved by the PDP
- line 162 - using MissingAttribute mechanism means development
of a more advanced test client and/or PEP, which I'd like to avoid; IMO,
the following approach would be simpler: requests are authorized based
on passed and/or retrieved attributes as defined above; all attributes
are expected to be available, and we limit testing only to positive
scenarios
Section 2.1.2
- lines 193-196 - addition of attribute management
significantly expands the scope of this use case, turning it into
"Management and Policy Exchange" use case, but doesn't contribute to
showing the actual product interoperability, which is the primary goal
of this exercise; if that's a desired piece of functionality for some
vendors, I'd suggest including it as an optional piece, which can be
demoed separately
- lines 196-197 - why do we need subject attributes and an
authentication service in this scenario? Again, this is about policy
exchange, and I don't think authentication is directly related to it
- Figure 3 - the PEP for "Manager client" doesn't really add
any value to this use case; although in real life all servers will have
this component, I think it is not directly relevant here
- Figure 3 - based on an earlier comment about attribute
management, I'd suggest removing the PIP box as well to simplify the
picture; if showing PIP functionality is desired, there might be a
separate figure created which shows relation of the PIP component to the
overall PAP service
- lines 202-204 - I think it's important to stress here (and,
maybe, mark it on the figure 3 as well) that "User client" and lower
PEP, shown in the figure 3, are not necessarily the same as in the
Section 2.1.1; they may be in some cases, but this can't be a hard
requirement, since we're trying to demo different type of functionality
and, correspondingly, this may require a different client and PEP
implementation
- lines 206-208 - again, in the spirit of simplicity, I'd
suggest starting with policy text files stored on shared drives, which
can be used to push/pull policies; this would allow decoupling the PAP
from PDP in the figure 3 and, as a result, significantly simplify
testing; once we agree on the set of policies to be exported/imported,
we'll be able to just write N policy files and each team can conducting
initial testing of their solution in isolation, before attempting a live
test; using the direct path PAP/PDP would force live testing from the
day one
- lines 212-216 - this directly corresponds to the point that
was made above; I think it's appropriate to add this text to the
paragraph following the figure 3
- lines 217-218 - as I said earlier, I'd suggest moving the PIP
functionality completely out of this use case
Regards,
Denis
_______________________________________________
Denis Pilipchuk
AquaLogic Enterprise Security group, BEA
Phone: 781-993-7232
denis.pilipchuk@bea.com________________________________
From: Rich Levinson [mailto:
rich.levinson@oracle.com]
Sent: Wednesday, April 18, 2007 17:46
To:
xacml-demo-tech@lists.oasis-open.orgCc: 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.comSubject: 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
:-) 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________________________________
From: Rich Levinson [mailto:
rich.levinson@oracle.com]
Sent: Wednesday, March 21, 2007 18:40
To:
dee.schur@oasis-open.orgCc:
staff@lists.oasis-open.org;
ggebel@burtongroup.com; Hal Lockhart;
prateek.mishra@oracle.com;
miken@burtongroup.com;
xacml-demo-tech@lists.oasis-open.org;
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.comSubject: [xacml-demo-tech] Re: [xacml] Groups - Call to discuss XACML
InterOp at Burton Catalyst added
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>
<mailto:rich.levinson@oracle.com>
To:
Dee Schur <dee.schur@oasis-open.org> <mailto: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>
<mailto:scott.mcgrath@oasis-open.org>
References:
<e1hryjn-00066p-rx@ms01.oasis-open.org>
<mailto: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> <mailto:dee.schur@oasis-open.org>
To:
<xacml-demo-tech@lists.oasis-open.org>
<mailto:xacml-demo-tech@lists.oasis-open.org> ,
<xacml@lists.oasis-open.org> <mailto:xacml@lists.oasis-open.org>
CC:
'Scott McGrath' <scott.mcgrath@oasis-open.org>
<mailto: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=14
763
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=14
763
UID:
http://www.oasis-open.org/apps/org/workgroup/staff/event.php?event_id=14
763
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.
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.
</mailto:scott.mcgrath@oasis-open.org></scott.mcgrath@oasis-open.org></mailto:xacml@lists.oasis-open.org></xacml@lists.oasis-open.org></mailto:xacml-demo-tech@lists.oasis-open.org></xacml-demo-tech@lists.oasis-open.org></mailto:dee.schur@oasis-open.org></dee.schur@oasis-open.org></mailto:e1hryjn-00066p-rx@ms01.oasis-open.org></e1hryjn-00066p-rx@ms01.oasis-open.org></mailto:scott.mcgrath@oasis-open.org></scott.mcgrath@oasis-open.org></mailto:dee.schur@oasis-open.org></dee.schur@oasis-open.org></mailto:rich.levinson@oracle.com></rich.levinson@oracle.com>