[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: ISSUE:[UC-7-0{1|2}:Enveloping]
I've spent a good amount of time thinking about the envelope/enveloping issues. Eve and I worked on XLink and XInclude which has gone through a somewhat similar analysis. The following lengthy treatise illustrates my rationale behind my voting. First thing to do is to look at characterising the differences in the approaches and the ramifications. Enveloping is where the top level construct of a message is a SAML construct, ie a SOAP 1.1 document. SAML must then define the dance/choreography of these messages. Hence a bindings and a protocol are required for SAML. If there is no enveloping requirement, then the protocols and bindings sections of SAML disappear. Enveloped is where the top level construct is a non-SAML construct, ie a CommerceOne business document. In this case the dance of messages and the bindings to other protocols is defined outside the scope of SAML so SAML only defines assertions. These discussions very much remind me of XLink, XInclude and Java O-O practices. Allow me to illustrate: XLink and XInclude both had the choice of specifying o an element based syntax, ie <xi:include href="xyz.html"/> o an attribute based syntax, ie <myNS:myElem href="xyz.html"/> where myElem was defined to be of "type" XInclude It turns out that XLink decided on an attribute based syntax to enable other vocabularies to re-use the attribute definitins. XLink is very much a data format and not a processing model (ie protocol). XInclude flip-flopped from element to atribute to element syntax. The decision seemed to favour element syntax because there was a processing model for XInclude and so it needed to be able to stand alone. We didn't want every potential consumer to have to create their own elements based upon XInclude. The issues around extensibility of element/attribute based syntax are pretty similar to enveloping/enveloped requirements, particularly around fitting into other vocabularies. In particular, XInclude has had to deal with whether or not/where to allow other vocabularies to extend it's syntax (same as enveloped), and XLink has had to deal with conformance of vocabularies that use it's syntax. One VERY important standards goal that we have not talked about much is that minimalism is good. Therefore it is probable that choosing BOTH enveloped and enveloping is a bad design. We should probably choose one. XLink and XInclude both decided that they could not support both syntaxes. So I ask myself which should I choose? Are we creating a data model or a processing model? It seems we have both. The SSO use case implies a processing model, whereas the intermediaries/B2B use case implies a data model. Now I fully realize that the processing model requires a data model. The issue is that if you vote for both, it seems that we cannot say an implementation is SAML compliant if it ONLY supports the data model. It has to support the higher construct (protocol) to be SAML compliant. I tried to think about how this would get used in a real world application. There are 2 different application models that I see. 1. Enveloping yields an application architecture that has a SAML application recieving the first request. So how would an application "register" interest in the non-SAML bits of the message? Seems like this could be very complicated, like a servlet/ejb programming model. There would have to be some way of defining an interface/programming model between the SAML app and the non-SAML app. Presumably this would be more complicated than SAX/XSLT pattern matches. I've spent a LOT of time dealing with server-side programming models, and this one seams really hairy about how to register interest in a part of a message, and then have it sent to the app. I guess the alternative is that the entire SAML request is passed to the next application, but that means that every application downstream must be "aware" of SAML aspects. 2. Enveloped yields an architecture that has a non-SAML app recieving the first request, then passing the SAML portion or entire request to a SAML application. Then SAML application presumably validates the SAML portion, returning true/false. So how does the SAML app know "where" in the message the SAML bits are? The app would have to register the places that assertions could occur, perhaps XPath expressions. Or I guess that app could do some XPath search to discover all the assertions, but run-time discovery seems inappropriate to me. I am having difficulties with this because I have never dealt with an open data format that mixes security information with application information in a multi-hop messaging environment. I have tried to think about how other message based systems dealt with it, but my MQ experience didn't yield anything useful because MQ doesn't have an open data format, nor did it genericly solve the problem of "who's on top". Thinking about object systems like EJBs/RMI/ didn't help me, though I hear we have a corba security expert on the staff. Now I don't know which architecture is the one (highlander principle) that we should target for SAML. This seems like it needs more exploration and discussion. Perhaps an expected system architecture section in the SAML domain model would illustrate how we see the architecture being used. I would really like to hear from the security experts who have built security in cross-domain messaging systems on their experience in this. After all this, I'm leaning towards voting for enveloping (then it can be standalone) and against enveloped, knowing that this means some of the B2B cases can't be met by SAML directly. I would see a B2B vocabulary using the SAML assertion point, but it wouldn't be described as a "SAML" application, nor would it be SAML conformant. Thanks for you kind attention and feedback, Dave Orchard XML Architect Jamcracker Inc., 19000 Homestead Dr., Cupertino, CA 95014 p: 408.864.5118 m: 604.908.8425 f: 408.725.4310 www.jamcracker.com - Sounds like a job for Jamcracker. > -----Original Message----- > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] > Sent: Wednesday, March 21, 2001 7:36 AM > To: 'Orchard, David'; security-use@lists.oasis-open.org > Subject: RE: ISSUE:[UC-7-0{1|2}:Enveloping] > > > My thinking is that in the real world, security is an > afterthought. People > will build systems that construct a business message and sign > it. When they > get around to thinking about providing Attribute Assertions > with it, they > won't want to change anything they are doing. > > For that reason I consider SAML enveloped in a business document to be > impractical. > > Conversly, Enveloping business documents in SAML seems more > likely. However, > I don't see why SAML can't just include a hash of the document in the > assertion, protected by the assertion signature. > > I admit I have not studied xmldsig's use of these terms, so I > may be missing > something. > > Hal > > > -----Original Message----- > > From: Orchard, David [mailto:dorchard@jamcracker.com] > > Sent: Tuesday, March 20, 2001 10:20 PM > > To: security-use@lists.oasis-open.org > > Subject: ISSUE:[UC-7-0{1|2}:Enveloping] > > > > > > I think that this issue has not nearly been debated enough to > > vote upon - I > > accept personal responsibility for my extreme busyness. > > > > It seems that issue #1 says the design for SAML means it's a > > set of verbs > > and nouns and it has an <xsd:any> element that allows > > extensions, and issue > > #2 says that an external vocubalary has <xsd:any> element > > that allows (SAML) > > extensions. > > > > I'm really unsure how to vote on these. I can argue for and against > > different combinations. The tricky part is that issue #1 > > means that we have > > to define verbs (the outer construct), and issue #2 says that > > we have to > > define nouns (something that can be embedded inside a > > different vocabularies > > verbs). > > > > Issue #1 instance > > > > <envelope> > > <body> > > <updateSession> > > <SAMLAssertions> > > </SAMLAssertions> > > <Extensions></Extensions> > > </updateSession> > > <body> > > <envelope> > > > > Issue #2 instance > > > > <envelope><body> > > <sendStuff> > > <myStuff></myStuff> > > <saml:SAMLAssertions> > > </saml:SAMLAssertions> > > </sendStuff> > > </body></envelope> > > > > In case #1, I see that the first piece of software that > > recieves a SAML > > request will be a SAML compliant piece of software. It will > > then have other > > parties registered for various pieces of the software. > > Whereas in case #2, > > the first piece of software will be generic and have a > > pipeline of flow, ie > > first step: validate saml components; second step: dispatch > to myStuff > > handler. > > > > It seems unclear to me which way an xml processor will > > operate on the data. > > I really think we should have more of an idea of how the > > software will use > > this and flesh out our domain model and interactions before > > voting on this. > > But that might just be the analyst in me. > > > > Dave Orchard > > XML Architect > > Jamcracker Inc., 19000 Homestead Dr., Cupertino, CA 95014 > > p: 408.864.5118 m: 604.908.8425 f: 408.725.4310 > > > > www.jamcracker.com - Sounds like a job for Jamcracker. > > > > ------------------------------------------------------------------ > > To unsubscribe from this elist send a message with the single word > > "unsubscribe" in the body to: > > security-use-request@lists.oasis-open.org > > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: > security-use-request@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC