Using PKI to Access the SiteScope API

Hi Experts,

 

 First

SiteScope- Ver. 11.24.241 64-bit JVM, build 165. RHEL 64bit

Ok, now my question,

 

We have two SiteScope installations:

1) SiteScope configured for 1-way SSL with username/password authentication
2) SiteScope configured for 2-way SSL (client certificate authentication) and LDAP.

We are attempting to use the SiteScope API to get monitor data from SiteScope.

As a starting point, we are using the API examples in SITESCOPE_HOME/examples/integrations/api

We are able to run the get_configuration.sh example against our server #1 that uses username/password authentication but get errors when we run it against the second SiteScope that uses 2-way SSL.  Specifically, we get a '500 Internal Server Error'

To support client certificate authentication for the examples we modified the examples/integrations/api/bin/run_api_call.sh script to add SSL-related properties that point to the JKS keystore and truststore, specifically: 

javax.net.ssl.keyStore
javax.net.ssl.keyStorePassword
javax.net.ssl.trustStore

When I look at the error log on the SiteScope server I see the following:

javax.servlet.ServletException: The username was not found in client certificate
    at com.mercury.sitescope.axis.CertificateAuthenticatedServletRequestHandler.getUsernameFromClientCertificateSubject(CertificateAuthenticatedServletRequestHandler.java:46)
[SNIP]

When we ran the SiteScope hardening script to configure SiteScope for 2-way SSL we specified that we wish to use 'Other Name' when asked for 'Please enter username property in client certificate AlternativeSubjectName field".  This configured SiteScope to extract the email address from our client certificates and use that as the username.

Should we be able to use the SiteScope API with our 2-way SSL-enabled SiteScope?
If so, what username/password should we provide for the API calls that require them?  (Our 2-way SSL SiteScope doesn't use username/password authentication so we typically don't define them)

 

Thanks,

 

Scott

Tags:

Parents Reply
  • Thanks Kenneth,

       

        We previously configured SoapUI as described in your link, when we do  we get the '500 Internal Server Error'.  

     

        I mentioned that we used the SiteScope Java API library.  We can turn on SSL debugging in our test application and see our application present the user's client certificate and eventually get the '500 Internal Server Error'.  If we configure our application to *not* send a client certificate (by not setting the 'javax.net.ssl' properties) we get SSL-related errors.

     

       Based on this, I think the core-SSL handshaking is working and   I suspect there is something else going on here.  When we configured SiteScope to use client-certificates and LDAP we used the hardening script to configure it to pull the user's e-mail address out of the Subject Alternate Name in his certificate. (This was the default option in the hardening script)  This works fine for users using their client cert to authenticate to the SiteScope web UI.

     

        I think there is a step in the SiteScope client-cert authentication process that attempts to extract a login name from the client certificate.  In the case of the SiteScope web UI, this is working and it grabs the user's e-mail address but when we try to use the same certificate/key through the SiteScope SOAP API, we get the error in the SiteScope error.log file that reads:


    javax.servlet.ServletException: The username was not found in client certificate

     

    Thanks,

       Bruce

Children
  • Interesting, that will require further testing and investigation. Again, what about using default admin user even from SoapUI?

  • Interesting, that will require further testing and investigation. Again, what about using default admin user even from SoapUI?

  • Interesting, that will require further testing and investigation. Again, what about using default admin user even from SoapUI?

  • Using the admin user/password for the parameters to the web service call in SoapUI results in the same 500 Internal Server Error.  

     

    When we enable SiteScope for client-cert authentication, the username/passwords defined thorugh Preferences->User Management Preferences aren't used since users are authenticated using their client certificates and authorization and role assignment takes place through LDAP.   So I'm not sure what I should be providing for the username/password parameters required by the API calls.

     

    The 'Using SiteScope' PDF describes toggling the Preferences->Infrastructure Preferences->Custom Settings->Access controlled property to require (or not require) username/password for API calls.   We have it set to 'true',  I'm reluctant to toggle that on our server since it seems like turning off access control can be dangerous but I'm wondering if that might be part of this.

     

    -Bruce

  • Using the admin user/password for the parameters to the web service call in SoapUI results in the same 500 Internal Server Error.  

     

    When we enable SiteScope for client-cert authentication, the username/passwords defined thorugh Preferences->User Management Preferences aren't used since users are authenticated using their client certificates and authorization and role assignment takes place through LDAP.   So I'm not sure what I should be providing for the username/password parameters required by the API calls.

     

    The 'Using SiteScope' PDF describes toggling the Preferences->Infrastructure Preferences->Custom Settings->Access controlled property to require (or not require) username/password for API calls.   We have it set to 'true',  I'm reluctant to toggle that on our server since it seems like turning off access control can be dangerous but I'm wondering if that might be part of this.

     

    -Bruce

  • Using the admin user/password for the parameters to the web service call in SoapUI results in the same 500 Internal Server Error.  

     

    When we enable SiteScope for client-cert authentication, the username/passwords defined thorugh Preferences->User Management Preferences aren't used since users are authenticated using their client certificates and authorization and role assignment takes place through LDAP.   So I'm not sure what I should be providing for the username/password parameters required by the API calls.

     

    The 'Using SiteScope' PDF describes toggling the Preferences->Infrastructure Preferences->Custom Settings->Access controlled property to require (or not require) username/password for API calls.   We have it set to 'true',  I'm reluctant to toggle that on our server since it seems like turning off access control can be dangerous but I'm wondering if that might be part of this.

     

    -Bruce

  • We opened a support ticket to help resolve the problem.  HP support sent the patches:

    SIS_00361_Win_x32
    SIS_00363_Linux-CentOS
    SIS_00371_Win_x64

     

    We tested the 00363 and we can now access the API with our PKI/LDAPed enabled Sitesscopes.

     

    Thanks,

     

    Scott