Before configuring and using the Secure Attributes Exchange, administrators must make some decisions regarding security-related settings such as cryptography type, applicable keys, and application identifiers. Administrators must be familiar with basic SAMLv2 concepts and the SAMLv2 samples bundled with OpenSSO Enterprise.
This section provides a high-level summary you need to resolve before configuring Secure Attributes Exchange.
Secure Attributes Exchange provides symmetric and asymmetric cryptography types to secure identity attributes between an instance of OpenSSO Enterprise and an application.
Symmetric cryptography
Involves the use of a shared secret key known only to the participants in the communication. The key is agreed upon beforehand and is used to encrypt and decrypt the message.
Asymmetric cryptography
Uses two separate keys for encryption and the corresponding decryption - one public key and one private key. The information is encrypted with a public key known to all, and then decrypted by the recipient only, using a private key to which no one else has access.
This process is known as a public key infrastructure (PKI). On the Identity Provider side, the public key must be added to the OpenSSO Enterprise keystore. The private key must be stored in a protected keystore such as a Hardware Security Module (HSM) for access by the Identity Provider application. On the Service Provider side, the private key must be added to the OpenSSO Enterprise keystore, and the public key stored in a keystore that is local to the Service Provider application.
Establish trust among the application or multiple applications and the instance of OpenSSO Enterprise on the Identity Provider. This includes the configuring the cryptography type, applicable keys, and application identifiers.
Establish trust among the application or multiple applications and the instance of OpenSSO Enterprise on the Service Provider side. This includes configuring the cryptography type, applicable keys, and application identifiers.
(Optional) The following steps are specific to using SAMLv2 with auto-federation.
Determine which identity attributes you want transferred as part of the SAMLv2 single sign-on interaction.
Determine which attribute you will use to identify the user on the Service Provider side.
Determine which URL on the Service Provider will be responsible for handling logout requests from the Identity Provider.