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


> 
> > e) The Service-Provider needs the user-identity for Audit Logging
> > purposes
> 
> It may need to know it, but does it need to know that the user is a
party
> to the transaction, or is it simply data that is part of the
transaction
> like any other part of it?
Our assumption is that the SAML assertion is more than just a fancy way
to send a username. But clearly I might not be fully aware of what more
I should expect to get out of the SAML assertion than a fancy way to
carry the username.
> 
> > f) The Service-Provider may need the user-identity for access
control
> > (RBAC) enforcement
> 
> Yes, but are you trusting the client to tell you that identity, or
does
> the user need to be a secure party to the flow?

We trust the client, ultimately we will be giving that client a copy of
patient data, so clearly we need to be trusting of the client. The TLS
authentication gives us this trust assertion. But this is simply saying
that the client system an be trusted to further protect the data that we
would expose it to. But this trust is a different level of trust than
trusting it as an identity issuer. 
There are times when the client is it-self an identity issuer, but this
is a degenerate case. Right?
So, we want the SAML assertion to be capable of being validated as it
might be issued by a trusted-third-party... hence federation. Right?
> 
> > 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.
> 
> That just sounds like data to me. Perhaps data that's signed itself by
> some authority, but with no security properties relevant to SAML. Or
OAuth
> for that matter.

I suspect from your words, that I am missing something. What 'security
properties relevant to SAML' are you referring to?

> 
> > So, somehow we need to carry the SAML assertion on the RESTful API.
> 
> I think it's just app content.
Could be. This is one approach we have thought of using. Just a
base-64-encoded blob of an attribute. But then what is the attribute
name? Is it a reference or the assertion it-self? Do we put it in
parameter or as HTTP-Auth? 
We could invent, but if inventing then we might as well ask how others
do this. 
> 
> > Are we using SAML wrong?
> 
> No, just somewhat superfluously.
Then we might simply not be understanding how to do it right? Or, I
hope, I am just not communicating well enough in this email thread.
> 
> >
> 
> What I was trying to figure out was why OAuth would be a candidate. I
> don't think it is, because your security here is server to server, not
> Token based.
I understand server-to-server. I understand not browser-to-server. But
what do you mean by 'not Token based'?
> 
> -- Scott


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