Force SAML 1 with Login handler?
tfpoage at ucdavis.edu
Fri Sep 23 22:12:39 BST 2011
I've discovered an SP who looks to have tried to "beat the clock" by
publishing a new signing/encryption key before restarting the SP with
the new key pair, i.e. didn't follow a rollover procedure.
I can't find a way to work around this other than to perhaps grab an old
copy of the metadata and use it until it breaks again when they restart
with the new keypair.
Is there a way from the client/IdP side to force using SAML 1 when
visiting the /Login handler?
(If not, since we maintain a launch URL for the SP, perhaps we can fall
back to the SAML 1 /Shibboleth/SSO profile handler)
More information about the users