SAML Signature/Encryption Certificate Change - Metadata Update

[PROFESSORE79]

Hi there,

maybe there's a trick I do not know of but you do - otherwise take this as a suggestion/feature request.

We renew our official certificates yearly which also affects federation - we use MS AD FS. We change all certificates to the public one - web server port, token signing, token encryption.
AD FS has a cool feature where a new signing/encryption certificate can be imported as secondary before the original (primary) expires. Thus all properly coded identity clients can refresh this from the metadata URL and see that there is now another legitimate certificate. After a grace period of a few days you switch the secondary certificate to primary.

Now my SAML authentication to ONTAP System Manager (FAS and AFF) is broken: "Message was signed, but signature could not be verified." This leads me to the conclusion that ONTAP does not properly handle the federation metadata and just evaluates this one-time instead of periodically retrieving AD FS metadata updates. Also the NetApp SAML Troubleshooting Guide makes no mention of a certificate change process or troubleshooting options. "saml repair" in Advanced has no effect. Therefore it seems a trip to the vault to recover the protected console passwords will be in order for a disable-enable SAML game.

Certificate management is a common operational task so NetApp ONTAP should handle this more intelligently - either by periodic metadata checks or at least some manual refresh capability, be it as part of the "repair" subcommand or something new like "metadata refresh" or what have you.

Thanks & regards,

Markus

[Ontapforrum]

There is a Kb which is related to ADFS and SMAL issue, I don't know if this is what you are running into?
https://kb.netapp.com/onprem/ontap/os/ONTAP_SAML_setup_fails_when_ADFS_server_has_a_self-signed_certificate

[PROFESSORE79]

Sorry for the late reply, answering directly per mail failed with notification just today.

Thanks for the good idea but no. The article is about creating a saml-sp config for the first time. I have a deployment that was working. We are not using self-signed certificates in this case (GoDaddy). And anyhow, as I verified now using “security certificate show-truststore”, the GoDaddy certs are properly imported.

My issue is about the inner flow of federation authentication token issuance. The certificate(s) used there could be different from the federation/IdP web server certificate. Although in our case they are not, still, configuring token signing/encryption certificates is usually a separate, specific configuration when establishing a WS-Fed/SAML or OAuth trust between relying parties and part of the configuration of an authentication middleware. In the NetApp case this detail configuration is hidden away behind the “saml create” command and generated “automagically” from the federation metadata URL. The metadata XML contains the info about the token signing/encryption certificate(s). If ONTAP used that info only once at the time of deployment (“saml create”) then it would now expect responses from the AD FS server being signed with a certificate not in use any longer – describing exactly the behavior/error message I see. Currently the only promising option I see is to “saml delete” and “saml create” to re-create the config.