OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[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