[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Multi-participant transactional workflows
Folks-- I did my action item to ask Ron about the issue with multi-participant transactional workflows, and here is his response. Eve -------- Original Message -------- Subject: Re: SAML TC question: multi-participant transactional workflows Date: Wed, 23 Jul 2003 17:05:21 -0400 From: Ron Monzillo <ronald.monzillo@sun.com> To: Eve L. Maler <eve.maler@sun.com> References: <3F1EEC9C.2020204@sun.com> Eve L. Maler wrote: > In yesterday's telecon we went over our list of candidate work items > for V2.0, and there was one that caused your name to come up: > "profiles for multi-participant transactional workflows". Here is the > whole exchange as recorded in the minutes > (http://lists.oasis-open.org/archives/security-services/200307/msg00048.html): > > > - Profiles for multi-participant transactional workflows > - Irving: guessing that this is for attaching assertions to > workflows > - characteristic of web browser profile is that assertions have > confirmation methods that render the assertions useless in > any other step of a workflow process (which is intentional) I thought the browser profile relied on the SenderVouches confirmation method, and that such assertions are "bearer tokens"; which means they may be used downstream of the web server/servlet container. I thought it was only the artifact that was single use. The (WSS) SAML token profile describes the use of SAML assertions with the SenderVouches confirmation method, and leaves open the possibility for the SenderVouches confirmation method to identify a confirmation key. My understanding is that some folks would like to use this form of assertion to enable a form of transparent impersonation, where the sender and the subject are different, and the sender must be able to demonstrate knowledge of the confirmation key to impersonate the subject. So I probably am not understanding something, but it would seem that assertions acquired by te browser profile could be used in a subsequent step. > > - Prateek: Irving for champion here? > - Irving: wouldn't be right person > - [ACTION] Eve to send Ron Monzillo question on profiles for > multi-participant transactional workflows > - Scott: may also be a possible champion > - basically doesn't think our assertions should be short-lived > > In the call, though it wasn't captured, someone asked a question here > about how J2EE could be made to allow for passing through of SAML > assertions. There has been some interest in defining another CSIv2/IIOP identity token form to accomodate SAML (SenderVouches) authentication assertions. CSIv2 defined an extensibility mechanisms to facilitate the integration of new Identity token forms. There is also interest in using SAML assertions via the SAML profile of WSS to authenticate SOAP msgs fro2m intermediates to downstream web services. This can be done with SenderVouches assertions (with or without a Subject Confirmation key) or with HolderOfKey Assertions where the key of the intermediate is in the assertion. Ron > > If you get to this before your vacation, great; if not, don't worry > about it. Thanks, and have a wonderful time away from all this! > > Eve -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Technologies and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]