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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]