[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Multi-participant transactional workflows
Polar, The primary purpose of my msg was to state my belief that SAML assertions are useful in intermediary scenarios. How best to integrate SAML in CSIv2 should likley be the subject of a separate thread, assuming their is interest within this forum. Ron Polar Humenn wrote: >Eve and Ron, > >I'm not familiar with the SenderVouches authentication assertion. So >please forgive me, if I have it wrong. I believe from the description >below that its purpose is to be an assertion that the sender authenticated >the identity for the purpose of impersonation (or delegation), thereby >"authorizing" the sender to act in the identity's behalf. There seems to >be a proposal to invent a new CSIv2/IIOP identity token type to hold this >assertion for this purpose. > >In the CSIv2 way of doing things, the SenderVouches assertion should be >transported, not in the Identity Token, but in the Authorization Token, >while the matching identity is transported in the Identity Token using one >of the standard formats. This approach basically says that the sender is >"quoting" the given identity, and the SenderVouches assertion in the >Authorization Token yields the proof (or authorization) that the sender >can indeed act as the quoted identity. > >I imagine that the SenderVouches assertion may be also be retrieved out of >band from the CSIv2/IIOP request. The standard identity is placed in the >Identity Token. Then, the SenderVouches assertion may be placed in the >Authorization Token or retrieved from some authorization system yielding a >similarity in the request formats with the two approaches. > >Transporting the SenderVouches in the Authorization Token is fairly easy >as the Authorization Token is a list of tagged data types. The Identity >token is more problematic as it is tagged as a bit mask. > >I'd like to maintain the integrity of the CSIv2 specification such that >the Identity Token is strictly used for asserting an identity, and the >Authorization Token is used to provide proof for the use of that identity. > >Cheers, >-Polar > >OMG Security SIG Chair > > > >On Wed, 23 Jul 2003, Eve L. Maler wrote: > > > >>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 >>> >>> >> >> >> >> >> >> >> >> > > >You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]