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

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

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


> -----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
> > with the TLS client-authentication?
> That's what "holder of key" confirmation means. The analagous spec is
> HoK Web Browser SSO profile, of which there is no ECP variant formally
> 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
> the user's original assertion if the client is not the user's system.
> would be done by exchanging the SSO token from the user for a
> token issued for use by the service. That token can be obtained via
> and
> bound to the service's key if client TLS can be used on the REST
> > 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
> the
> tiers yet, it's bearer initially. The next phase after improving the
> would be adding HoK.
> https://spaces.internet2.edu/display/ShibuPortal/Solution+Proposal
> That is much stronger than the crazy things people do passing around
> 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

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