Shibboleth Developers

["Scott Cantor" <>]

> Ah, it's all coming back to me now....   I suppose that's the right thing
to
> do from a "be safe" standpoint.    FYI, so looks like we currently default
> (based on the config file schema) to attribute push with no encryption.

I would personally like to see encryption on by default for SAML 2. Right
now, we've always relied on the SP having a key, so I would see that as a
minimal change. It's a big change for other SAML deployments that are push
only, but with the callback, we sort of hit all that pain up front, may as
well take advantage of it.

Note that it won't affect any truly existing deployments, since they're not
SAML 2 anyway. If you give it most federation's metadata without keys,
nothing breaks since only SAML 1/Shib are supported there anyway.


> So if people turn on encryption of assertions or name ID's for the default
> relying party, then they'll need to know to override and turn it off for
> specific relying parties that don't publish keys, or it will result in a
> fatal error for the latter.

I think that's acceptable in light of the general attitude that encryption
is the right thing to do.

>> I also think both front and back channel should be controllable
>> independently. I have that ability, but not the former right now.
> 
> Also sounds reasonable.  Were you going to add the former?  Or not for
2.0?

I don't know yet, probably not, because the SP can normally count on the IdP
having a key, and for 2.0 there won't be much encryption that direction
anyway.

-- Scott