FW: [xacml-demo-tech] XACML InterOp at Burton Catalyst

Please review.

Cheers,

Dee

From: Mark O'Neill [mailto:mark.oneill@vordel.com]
Sent: Monday, April 09, 2007 12:08 PM
To: dee.schur@oasis-open.org
Subject: FW: [xacml-demo-tech] XACML InterOp at Burton Catalyst - scenario comments

Hi Dee – I tried to send this but I don’t think I’m on the appropriate lists

Feel free to forward anything

Thanks

-Mark

From: Mark O'Neill [mailto:mark.oneill@vordel.com]
Sent: Monday, April 09, 2007 11:42 AM
To: 'Denis Pilipchuk'; 'Rich Levinson'; 'dee.schur@oasis-open.org'
Cc: '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'; '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: RE: [xacml-demo-tech] XACML InterOp at Burton Catalyst - scenario comments

Hi –

Here is some feedback based on a XACML PEP/PDP deployment for a telecoms customer which was deployed in 2005, and is in production today. The customer is using Vordel and Entrust products. The Vordel XML Gateways delegate AuthZ to the Entrust access control platform using the SAML AuthorizationDecisionQuery message.

I’ve attached a public document describing the customer deployment, which was published in the ISTR journal but which I notice now costs money for reprints. Here is the Word doc original. SAML 1.1 was used at the time.

One big item which I’d pull out of this document and feed into the interop scenarios is that it would be good to add scope for multiple PDPs. For this customer, it was important that there was no single point of failure. So, we cycle between different PDPs and if one becomes unavailable, there are still other PDPs there (configuration screen here: http://radio.weblogs.com/0111797/images/saml_pdp_url_grp.gif , Full description at: http://radio.weblogs.com/0111797/2007/01/22.html#a73 ). When the PDP comes back online, we start using it again. Now, I don’t think we should have all of this in the interop, but it would be good to counter the question about whether using a single PEP/PDP introduces a single point of failure. Certainly, for the customer whose deployment is described in the document, a single point of failure was not an option, and they focused much of their acceptance testing on this aspect of the solution.

Hope this helps

Mark.

Mark O’Neill

CTO, Vordel

www.vordel.com

Phone: 617-848-0984

From: Denis Pilipchuk [mailto:dpilipch@bea.com]
Sent: Friday, March 23, 2007 2:22 PM
To: Rich Levinson; dee.schur@oasis-open.org
Cc: 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.com
Subject: RE: [xacml-demo-tech] XACML InterOp at Burton Catalyst - scenario comments

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:

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

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

Authorization Decision scenarios:

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

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

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

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.

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.org
Cc: 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.com
Subject: [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>
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.

This e-mail is business-confidential and may be privileged. If you are not
the intended recipient, please notify us immediately and delete it. If the
email does not relate to Vordel's business then it is neither from nor
authorized by Vordel. Thank you.

--
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.18.4/702 - Release Date: 2/25/2007 3:16 PM

xacml message