As you plan your deployment, consider the following assumptions, dependencies, and constraints to determine if your environment is appropriate for using the Fedlet.
The configuration file and the metadata for the Fedlet is stored in a flat-file repository at the Service Provider.
This solution uses the HTTP POST bindings for transport between the Identity Provider and the Service Provider.
The Fedlet supports the verification of the XML signature carried in the SAML Assertion from Identity Provider. XML signature verification is done using the Identity Provider public certificate included in the Identity Provider metadata XML file. If the Identity Provider signing certificate is changed, the Identity Provider metadata in the Fedlet configuration directory must be updated to include the new signing certificate information. Otherwise XML signature verification will fail on the Fedlet side. At this time, the Fedlet does not support XML encryption, XML decryption, or XML signing such as signing the AuthnRequest on the Fedlet side.
The Fedlet supports Identity Provider-initiated single sign-on using only HTTP POST bindings.
The Fedlet supports Fedlet Service Provider-initiated single sign-on using only HTTP POST bindings.
In this deployment, no keystore exists to store certificates used for encrypting and signing SAMLv2 message elements. The Fedlet does not support the encryption and signing of SAMLv2 message elements. This capability may be implemented in a future release of OpenSSO Enterprise. This constraint has implications about ensuring the confidentiality and integrity of messages. Until the Fedlet can support the encryption and signing of SAMLv2 message elements, you are encouraged to use SSL/TLS at the message transport layer to secure exchanges between browser and server. The ensures that exchanges are secured at least while the SAML messages are in-transit. The Fedlet does support the verification of XML signature in the SAMLv2 Response from Identity Provider.