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