About the BIRT iHub SAML implementation
BIRT iHub provides its own out-of-the-box (OOTB) SAML identity provider (IdP) implementation. BIRT iHub does not support other third-party SAML identity provider software. BIRT iHub uses Shibboleth IdP 2.4.0 to implement this feature with some customization.
BIRT iHub implements single sign-on (SSO) in SAML 2.0, using the Shibboleth OpenSAML API for System Console, Information Console, and BIRT Analytics. BIRT iHub uses the default authentication method, which specifies PasswordProtectedTransport and PreviousSession.
BIRT iHub enables SSL by default, specifying port 8001 in the acpmdconfig.xml file. BIRT iHub stores SSL certificates in the AC_SERVER_HOME/shared/credential folder.
BIRT iHub implements 2048 RSA private key encryption. Actuate supports the following secure protocol configurations:
*SSL V3 and TLSV 1.0
*TLSV 1.1 and TLSV 1.2
BIRT iHub disables SSL V2, client-initiated renegotiation for ihubd, and TLS compression.
Understanding SSL
SSL, or Secure Sockets Layer, is a protocol for securely exchanging information on the internet. SSL provides the means to:
*Encrypt the data exchanged between two parties.
*Establish trust between the two parties by proving identity.
SSL uses the following components:
*Public key
Available to the public. Used to:
*Encrypt a message sent to the owner of the private key.
*Verify the digital signature on a digital certificate.
*Private key
Available only to the owner of the private key. Used to:
*Decrypt a message encrypted by the public key.
*Sign a digital certificate using a digital signature.
*Digital certificate
Contains information such as the certificate issuer, certificate expiration date, information about the certificate owner, and the certificate owner’s public key. The certificate is signed by the certificate issuer, using a digital signature.
*Certification authority (CA)
A trusted agency that validates information about an entity such as an online business, then creates a digital certificate for the entity.
As an example, a client user wants to purchase a product from an online business. The client user contacts the online business over the internet. The online business sends its digital certificate back to the client, which contains a digital signature. The private key is required to create the digital signature. The client uses the public key to verify the signature. If the public key can verify the signature, the response indicates that the corresponding private key was used to sign the certificate.
The client must verify that the signer of the certificate is in fact a trusted party, such as a Certification Authority. The client possesses a list of root certificates, each signed by a trusted party or Certification Authority. The client compares the signature on the digital certificate that the online business sent to the client against the signature on the root certificate of the Certification Authority whose name appears on the certificate the online business sent. If the signatures match, the identity of the online business is authenticated. The client and the online business now have a secure connection.
Understanding SSO
Single sign-on (SSO) refers to any authentication mechanism that supports a user logging in once to gain access to multiple applications. Single sign-on authenticates the user for every application the user is authorized to access and eliminates the need for the user to log in again when switching to another application during a session.