IdP assertions encryption issue
Cantor, Scott
cantor.2 at osu.edu
Wed Jan 31 13:12:23 EST 2018
On 1/31/18, 12:56 PM, "users on behalf of Tom Scavo" <users-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:
> Let me see if I understand what you're saying...if an IdP can not (or will not) encrypt the response, it should send use
> artifact. Is that what you are recommending?
It's an SP decision, so I'm saying I am moving to the view that one of encryption or artifact is required when it's our data. But I don't support artifacts and I'm not going to start, so that doesn't leave much. And I don't have any plans to force federated SPs that are handling data that isn't ours to do this because the risk is theirs to take.
I think I will have backing from my very security-conscious organization that encryption is going to be a requirement for anything hosting *our* data, ie. the cloud stuff. Anything else will end up getting filed as a security exception, which we conveniently have no actual process for dealing with.
Of course the whole point of not supporting encryption in a lot of cases (*) is key avoidance. SAML artifact usage practically speaking requires the SP have a key anyway. OIDC does not, which disqualifies it for me from serious consideration, but also is at least an internally consistent decision as to why to prefer the back channel.
-- Scott
(*) There are obviously SPs that simply don't want to do the work, but once you're down that slope, you're doomed to fail anyway and this is a great excuse not to work with them.
More information about the users
mailing list