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

["Toby Considine" <Toby.Considine@gmail.com>]

I am always fascinated by the assertions that SOAP is too complex and all
you need is REST so you can have simple interactions--an observation which
remains unexamined as ever more brittle ziggurats are built atop REST. There
are reasons to choose each. If you have to strain as hard as one does on
this thread, perhaps you have chosen the wrong one.




"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc
OASIS Technical Advisory Board
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com



-----Original Message-----
From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com] 
Sent: Friday, June 25, 2010 4:33 PM
To: Scott Cantor; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] RE: How to provide SAML assertions in RESTful
services

The usecase is:
a) NOT a browser use-case. 
b) The user is using a smart system (might be client/server, might be
standalone smart system, etc).
c) the smart system is using a RESTful API to access patient data at a
Service-Provider. 
d) The Service-Provider will use TLS mutually-authentication so the two
'systems' are well authenticated. This keeps out non-trusted systems.
Preventing at TLS level bruit-force attacks from malicious use
e) The Service-Provider needs the user-identity for Audit Logging purposes
f) The Service-Provider may need the user-identity for access control
(RBAC) enforcement
g) We want to use SAML because the client (b) may be in a different
organization than (f). They have a system-to-system trust relationship, but
this does not extend to being allowed to do LDAP queries from one
organization to the other. So we would like the SAML assertion power to
carry these additional user properties, including LOA.

Is that good enough environment and use-case ?

So, somehow we need to carry the SAML assertion on the RESTful API. 

Are we using SAML wrong?

John

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Friday, June 25, 2010 2:54 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
> 
> > So what specification do you use to associate a user's SAML
assertion
> > with the TLS client-authentication?
> 
> That's what "holder of key" confirmation means. The analagous spec is
the
> HoK Web Browser SSO profile, of which there is no ECP variant formally
but
> the idea is the same.
> 
> I don't know if this is the user's assertion here. Why would it be? If 
> this is an n-tier use case, this is delegation. It is generally 
> invalid to
use
> the user's original assertion if the client is not the user's system.
That
> would be done by exchanging the SSO token from the user for a
delegation
> token issued for use by the service. That token can be obtained via
ECP
> and
> bound to the service's key if client TLS can be used on the REST
calls.
> 
> > And is this in addition to authenticating the client system?
> 
> You haven't sufficiently defined the use case, let's put it that way.
> 
> But what I think you're doing is exactly what we did for delegation of 
> service access. We haven't done a variant of it with client TLS
between
> the
> tiers yet, it's bearer initially. The next phase after improving the
code
> would be adding HoK.
> 
> https://spaces.internet2.edu/display/ShibuPortal/Solution+Proposal
> 
> That is much stronger than the crazy things people do passing around
SSO
> tokens without regard for their security properties.
> 
> -- Scott
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: saml-dev-help@lists.oasis-open.org