SAML 2.0 Authentication type requires some configuration steps regarding the creation of certificates and the setup of the servlet's server in some cases (using Java generator). This document explains in detail the steps that should be considered.
This is useful for completing the Credentials tab information of SAML 2.0 Authentication type configuration.
First, note that, for testing purposes, you will not need a valid CA certificate. A self-signed certificate will do.
Listed below are some examples of how certificates can be generated for some of the most used Identity Providers, in some examples the way they are generated is separated by Environment (Java or .Net Framework), however, the resulting certificate extensions .jks or .pkcs12, .p12 and .pfx for Java or .Net Framework respectively, is independent of the Identity Provider and directly related to the Environment.
Note: These are just a few examples of some of the most commonly used Identity Providers, it is up to the developer to investigate on their own how to obtain the IDP certificate in cases that are not covered here.
openssl req -newkey rsa:2048 -keyout key.pem -x509 -days 365 -out certificate.pem
As a result, you'll have key.pem containing the private key, and certificate.pem containing the public key.
For Agesic, you have to change the format of the file containing the public key, and turn it into a .crt file (the certificate to be sent to Agesic):
openssl x509 -outform der -in certificate.pem -out certificate.crt
The certificate used to sign the request (of the Service Provider to the Identity Provider) should have the following characteristics:
-
RSA
-
2048 key length
-
SHA256 algorithm
-
No flags
You will need to change the format of the file containing the private key and turn it into a .pfx file in order to have it referenced in the Key Store Path property of the Request Credentials section of SAML 2.0 Authentication type configuration. Use the same password used to define the certificate in the step described above.
openssl pkcs12 -export -in certificate.pem -inkey key.pem -out certificate.pkcs12
For configuring the Response Credentials section of SAML 2.0 Authentication type, bear in mind that you must create a Keystore using the Agesic-Coesys-Testing.cer file provided by Agesic.
cd c:\Program Files\Java\jdk1.8.0_20\jre\bin
keytool -importcert -trustcacerts -noprompt -storepass changeit -alias 1 -file c:\temp\Agesic-Coesys-Testing.cer
openssl pkcs12 -export -in certificate.pem -inkey key.pem > server.p12
keytool -importkeystore -srckeystore C:\temp\server.p12 -destkeystore server.jks -srcstoretype pkcs12
As a result, you'll have a .pks file that must be referenced under the Trust Store Path property of the Response Credentials configuration.
You can use OpenSSL to generate a key pair as explained above.
To Request credentials, take a look at the credentials request section in this document, as it must be considered for both SAP and Agesic.
You must convert the certificate provided by SAP to read the response in X509 format. To this end, you may use samlTool.
Then save the result to a .pem file.
Afterwards, execute the following:
cd C:\Program Files\Java\jdk1.8.0_162\bin
keytool -import -file C:\cert\sapkey.pem -keystore C:\cert\sapkeystore.jks
You may generate a new alias by executing:
-alias newAlias
You can use a keytool to generate a keyresponse.jks as explained above. Download Java JDK from here.
First, download the certificate provided by OKTA and then convert it to a keyresponse.jks.
In a command line, go to the folder where you have the keytool app.
cd C:\Program Files\Java\jdk-18.0.2.1\bin
Note: This is the standard location. Your location could be different depending on your installation.
When you are there, execute the following:
keytool -importcert -trustcacerts -file C:\...\okta.cert -alias alias -keystore keystoreresponse.jks
Note: The path of your okta.cert that you enter in -file depends on where your certificate is placed. The -alias and -keystore are up to the developer.
After that, a file.jks will be created in the current directory.
In .NET you cannot use a Java KeyStore.
You can use a keytool to generate a keyresponse.jks as explained above. Download Java JDK from here.
First, you have to generate a Trust Store.
In a command line, go to the folder where you have the keytool app.
cd C:\Program Files\Java\jdk-18.0.2.1\bin
Note: This is the standard location. Your location could be different depending on your installation.
When you are there, execute the following:
keytool -genkeypair -alias mycert -keyalg RSA -keysize 2048 -validity 3650 -keystore keystore.jks //Command that generates a TrustStore
keytool -genkeypair -alias myalias -keyalg RSA -keystore keystore.jks -keysize 2048 -validity 365 -storepass mypassword -keypass mypassword //Command that generates a key
The generated key will be stored in the keystore.jks file. Be sure to replace myalias, keystore.jks, mypassword and other values according to your needs.
First, download the certificate provided by Azure and then convert it to a keyresponse.jks.
keytool -importcert -trustcacerts -file C:\...\Azure.cert -alias alias -keystore keystoreresponse.jks
Note: The path of your Azure.cert that you enter in -file depends on where your certificate is placed. The -alias and -keystore are up to the developer.
After that, a file.jks will be created in the current directory.
When working with .NET and Net Framework you cannot use a Java Trust Store.
In a command line, go to the folder where you have the keytool app.
cd C:\Program Files\Java\jdk-18.0.2.1\bin
Note: This is the standard location. Your location could be different depending on your installation.
When you are there, execute the following:
keytool -genkey -alias alias -keystore keystore.p12 -storetype PKCS12 -keyalg RSA -storepass yourpass -validity 730 -keysize 4096
This command will generate a keystore.p12 file.
After that, just put the path in the gam backoffice in Response Credentials.
Certificates and encodings