- Three pages have been merged to create this, does it make sense? Deborah Cross (Unlicensed). Also resolve linkages.
...
There are 2 main security options to choose from depending on your infrastructure.
- Mutual Authentication
- Password
...
All connections to the API must be protected by encryption, i.e. plain text transmission is not permitted under any circumstances.
Authentication is performed with the combination of accountId and password fields. However, mutual SSL authentication can be used if preferred. To use mutual SSL authentication, please contact us. When using mutual SSL authentication, the customer must provide a client certificate as part of the handshake process. The client certificate can be signed by our private certificate authority, or an external CA. If an external CA is used, Edentiti needs to know which CA in case so that the CA certificate needs to can be imported into the greenID truststore.
...
If you choose to use Mutual Authentication then you can provide a Certificate Signing Request (CSR) which Edentiti will sign with its private CA, or if you have a signed certificate you can just provide the trusted public CA certificate of the signing body. Edentiti will not only check to see that the certificate is signed by a trusted body, but it will also examine the content of the certificate to ensure that the certificate owner can only perform web service calls on the correctcustomerIdcorrect accountId . As a certificate cannot be tampered with, this ensures that no other customer can retrieve information about your users.
As part of your User Acceptance Testing, it's important you allow time to test that you can connect over Mutual Authentication in the greenID production environment. Your greenID system will be migrated to production approximately 2 weeks after final sign-off of your greenID configuration, so this timeframe plus a testing period should be factored into any project planning.
Note that the WSDL's for the MSSL web services also list a password argument to all the calls, however this is is ignored when the MSSL endpoints are used and is present only maintain a consistent interface for all our web service endpoints.
Setup
We use the following process to configure mutual authentication for test and then for production.
There are two options that you can choose from depending upon your needs and current setup. Our preferred option is for us to generate and sign a certificate using the Edentiti private certificate authority.
...
- Send us a certificate signing request (CSR) for your application infrastructure.
- We will generate a certificate using the CSR, pass that certificate to you and then add that certificate to our trusted list of certificates for your test or production account.
- You need to add that certificate to your application server as a client certificate.
- To test the trust has been setup, retrieve the appropriate MSSL WSDL from the server that has the certificate installed on it.
...
- Provide us with the client certificate that is installed on your server and the public certificate of the signing certificate authority.
- We will add that certificate to our trusted list of certificates for your test or production account.
- To test the trust has been setup, retrieve the appropriate MSSL WSDL from the server that has the certificate installed on it.
Password
Even without Mutual Authentication the web service calls are conducted over HTTPS, ensuring that the contents are safe from observers. So a second option is to provide a password with the web service calls.
To use password authentication you will need to provide a password with every web service call you make. The signatures of the web service calls outlined in this document assume Mutual Authentication so do not explicitly mention the password field. The password will be provided to you with your customerIdyour accountId.
If you choose password authentication then every web service call outlined in this document will also have an extra field of type String called passwordrequire a password with each request.