This page enumerates some outstanding issues using F5 as a SAML Service Provider within NIEF.
Be aware that some of these issues may eventually be fixed and the list will try to be updated as these fixes occur.
It looks like there might be canonicalization issues when an attribute value includes unicode (or perhaps any non-standard character). It's entirely possible that this is not a F5 bug, but a Shibboleth and/or SAML in general issue. Regardless, it was identified that Shib -> F5 communication failed when an attribute value included a non-standard character.
SAML Metadata / Importing New Entities
- If the SAML entity supports multiple certificates, F5 is likely to only work with one of these certificates (and it's not likely to be clear which certificate it is using). Likely the metadata should be reduced to specify only a single certificate prior to importing.
- F5 may not parse out the SSO bindings correctly when determining what URL to use for SAML SSO (specifically, it will try and use the Shibboleth endpoint for a default Shibboleth IDP metadata file instead of the SAML endpoint). At a minimum review the endpoint URL for correctness when importing.
Unsolicited SSO (aka IDP Initiated SSO)
F5 either does not support unsolicited SSO (as it requires a cookie specifying which IDP handler to process a given assertion with prior to processing it).
SAML Redirect Binding
F5 currently does not support the SAML Redirect Binding. There is an outstanding bug that they are working on, so a hot fix may be available soon.
Assertion Size Limitations
F5 can panic on really large assertions (generated when many, many attributes and/or attribute values) are transmitted in an SAML SSO Assertion. When it fails like this it fails to respond to the HTTP message entirely leaving most browsers to appear to have failed at the IDP.