RE: [saml-dev] RE: How to provide SAML assertions in RESTful services

["Moehrke, John (GE Healthcare)" <John.Moehrke@med.ge.com>]

I think you are being overly pessimistic. The scope of what I am doing
right now is defining the interoperability mechanisms. The operational
choices are above and beyond what we define in the interop profile.
Specifically with SOAP and WS-Security the capabilities of WS-Security
are available to be used. All we have done is eliminate the other token
types, specifying that the token for user identity would be SAML, we
haven't even limited the SAML profiles used. I would hope that this is a
useful profiling. These choices are primarily due to the sensitive
nature of healthcare, and the extremely distributed organizational
arrangements.

Does this give you more room to express security concerns?

John

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Saturday, June 26, 2010 1:14 PM
> To: Moehrke, John (GE Healthcare); saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] RE: How to provide SAML assertions in RESTful
> services
> 
> > We (Healthcare security geeks) agree. And part of the effort is to
> > identify the residual risks associated with RESTful vs SOAP
solution. It
> > is only by exposing these explicitly that we will make progress. So,
I
> > implore you to help me itemize the problems associated with taking a
> > well defined SOAP solution that leverages WS-Security and forcing a
new
> > interface to be built that is RESTful.
> 
> As I understand what you've subsequently described, I don't think
there
> are
> differences in risk because the security here is just mutual TLS. REST
> actually works best when there is no security, or the security can be
> confined to the HTTP (or TLS) layer. Seems like it's a pretty good fit
> here.
> 
> I don't think it's possible to itemize problems with WS-Security in
> general
> because WS-Security is not a protocol with any real semantics. It's
> framing.
> You need the protocol and the token content/semantics (including how
> they're
> obtained, of course) before you can talk about risks.
> 
> -- Scott
>