IBM Security Access Manager Appliance Local Management Interface Certification Authentication and Authorization

Answer

Assume a configuration with the following set:

https://appliance_lmi_hostname/admin_cfg -> Administrator Settings:

Accept Client Certificates: True

The RAPIs are being used for administration.  If a certificate is presented that is not signed by a CA in the lmi_trust_store the TLS handshake is shutdown.  The BA header is not consumed.  For example:

curl -v -s -k -u admin:admin --cert ./untrusted.crt --key ./untrusted.key ...

* NSS error -5938

* Closing connection #0

* SSL connect error

and in the LMI trace.log file there is:

[1/24/20 18:24:59:794 CST] 000005f4 id=00000000 com.ibm.ws.ssl.core.WSX509TrustManager            E CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN EMAILADDRESS=user@example.org, CN=user, O=IBM, ST=TX, C=US was sent from the target host. The signer might need to be added to local trust store /var/pdweb/shared/keytab/jks/lmi_trust_store.jks, located in SSL configuration alias defaultSSLSettings. The extended error message from the SSL handshake exception is: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:

    java.security.cert.CertPathValidatorException: The certificate issued by EMAILADDRESS=ca@example.org, O=IBM, L=Austin, ST=TX, C=US, CN=CA is not trusted; internal cause is:

    java.security.cert.CertPathValidatorException: Certificate chaining error

Now take the case of presenting two certs that are signed by a CA in the lmi_trust_store (cn=admin and cn=log-reader).  There are no additional users defined at https://appliance_lmi_hostname/sysaccount.

With the following settings login is successful with both certs.  It is basically a blind trust:

Accept Client Certificates: True

Validate Client Certificate Identity: False

Exclude CSRF Checking: .*admin*,.*log-reader*

With the following settings only login using cn=admin  is successful:

Accept Client Certificates: True

Validate Client Certificate Identity: True

Exclude CSRF Checking: .*admin*,.*log-reader*

There is not a user named log-reader (cn=log-reader) so a 403 is returned:

Once a user named log-reader is created login is successful:

curl -v -s -k --cert ./log-reader.crt.pem --key ./log-reader.key.pem -H "Accept:application/json" -X GET https://appliance_lmi_hostname/events/system

... <all the events are exported>

The value comes when enabling LMI Management Authorization with Roles.  With Roles now enabled:

curl -v -s -k --cert ./log-reader.crt.pem --key ./log-reader.key.pem -H "Accept:application/json" -X GET https://appliance_lmi_hostname/event_log/events/system

{"error":"You do not have permission to perform the requested action on the following feature: Event Log"}

The user log-reader needs explicit access to read the event logs.  Even if a BA header for admin is sent login is still denied:

curl -v -s -k -u admin:admin --cert ./log-reader.crt.pem --key ./log-reader.key.pem ...

< HTTP/1.1 403 Forbidden

{"error":"You do not have permission to perform the requested action on the following feature: Event Log"}

So to sum it up:

1. A cert's signer must be in lmi_trust_store or the TLS handshake is shutdown.
2. With "Validate Client Certificate Identity: False" and LMI Management Authz disabled it is a blind trust and login can do anything.
3. With "Validate Client Certificate Identity: False" and LMI Management Authz enabled it is a blind trust but Roles apply.
4. With "Validate Client Certificate Identity: True" and LMI Management Authz disabled it is not a blind trust.  User must exist but then can do anything.
5. With "Validate Client Certificate Identity: True" and LMI Management Authz enabled it is not a blind trust.  User must exist and Roles apply.
6. The BA Header is never consumed in anyone of the above as an override.