Table of Contents

Introduction

Apache-Based Authentication

Basic Authentication

Shibboleth

Tomcat-Based Authentication

Troubleshooting

Relevant Links

Introduction

OA4MP supports Apache- and Tomcat-based authentication. This document provides a walk-through of two Apache methods, basic and Shibboleth, and Tomcat basic authentication. Apache and Tomcat provide a number of other authentication methods, but anything using the REMOTE_USER variable should work with OA4MP.

Since only effectively the user name can be sent to the authorization servlet, another requirement is that the client have a certificate with the Myproxy server so that passwords are not needed.. Said more plainly, if this is enabled and required, no password will be sent to the MyProxy server.

Tomcat can either run standalone, or it can run behind the HTTP server. For the Apache-based methods, it will need to run behind HTTP. For Tomcat-based authentication, it can run standalone.

Be sure you look at the authorization header block in the configuration file to tell your install that you are replacing the default component with your own.

Apache-Based Authentication

Apache Basic Authentication

Apache basic authentication is the simplest form of Apache authentication. In this example, we’ll use two modules: proxy_ajp to allow Tomcat and Apache to communicate via the AJP protocol, and auth_basic to protect a location (prompting the user for login and password).

proxy_ajp.conf

Connect Apache to Tomcat using the AJP module. You can do this by editing the file /etc/httpd/conf.d/proxy_ajp.conf (or whatever path your OS uses).

This is what the file on our test server looks like:

ProxyPass /oauth/authorize ajp://localhost:8009/oauth/authorize
ProxyPass /client ajp://localhost:8009/client
ProxyPass /oauth/initiate ajp://localhost:8009/oauth/initiate
ProxyPass /oauth/token ajp://localhost:8009/oauth/token
ProxyPass /oauth/getcert ajp://localhost:8009/oauth/getcert

auth_basic.conf

Now that HTTPD is connected to Tomcat, we need to configure an HTTPD authentication module to protect access. In this example we use the Basic Auth module. On most Linux servers, this file is located at /etc/httpd/conf.d/auth_basic.conf . Here is what we added to use Apache basic authentication to protect the location "/oauth/authorize":

  AuthType Basic
  AuthUserFile /var/www/config/validusers
  AuthName "Protected Area"
  require valid-user

We used htpasswd to create the file /var/www/config/validusers . Our users are "testuser1" and "testuser2" and this is where the passwords are set. If you need information about how to use "htpasswd," there’s some documentation available at http://httpd.apache.org/docs/2.2/programs/htpasswd.html . Make sure that the password file is readable by Apache.

server-cfg.xml

OA4MP uses the server-cfg.xml file in the designated directory to configure the server. Apache authentication won’t work on port 8443, so in the server-config.xml file, port 8443 will need to be removed from the service address value. For example,

service address="https://shibber.ncsa.illinois.edu:8443/oauth" 

should be changed to

service address="https://shibber.ncsa.illinois.edu/oauth"

For Apache authentication, we also need to specify a keystore in server-cfg.xml (as part of the "service" element) as a credential for authenticating to the MyProxy server. This is how we have done it on our example server:

<service ....>
<keystore path="/var/www/config/hostcred.p12"
          type="pkcs12"
          password="whatever"
          factory="SunX509"
          useJavaKeystore="true"/>
       </myproxy>
<.... /service>

Note: The file hostcred.p12 was using the files hostcert.pem and hostkey.pem in /etc/grid-security. We used the command below to generate it:

openssl pkcs12 -export -in /etc/grid-security/hostcert.pem -inkey /etc/grid-security/hostkey.pem -out hostcred.p12

client-cfg.xml

Also remove port 8443 from your client-cfg.xml file since you'll be sending your requests directly to Apache.

myproxy-server.config

Edit the myproxy-server.config file on the server where the MyProxy server is to trust the OA4MP installation. Set trusted_retrievers to the DN of the credentials that the OA4MP server will use to authenticate to the MyProxy server (i.e., /var/www/config/hostcred.p12 in the above example).

You can use openssl to view certificate information. For a p12 certificate, you would use the command openssl pkcs12 -info -nodes -in hostcred.p12 to see the information for that certificate. The DN is listed in the subject= line of the openssl pkcs12 output.

Below are some sample changes for /etc/myproxy-config on oa4mp-server.example.edu.

Added authorized retrievers:

authorized_retrievers "/C=US/O=National Center for Supercomputing Applications/OU=Services
/CN=oa4mp-server.example.edu"

Added trusted retrievers:

trusted_retrievers "/C=US/O=National Center for Supercomputing Applications/OU=Services
/CN=oa4mp-server.example.edu"

grid-mapfile

On shibber, we defined "testuser1" and "testuser2" so our grid-mapfile looked like

"/CN=Test User 1" testuser1
"/CN=Test User 2" testuser2

The users should correspond to the users defined in the password file that will be used by Apache. The Apache user needs to be mapped to a DN using either the myproxy-server.config certificate_mapfile (as in the example above) or certificate_mapapp settings.

Authentication with Shibboleth

Shibboleth authentication also uses Apache. First, you'll need to set up Shibboleth with an appropriate identity provider (IDP). For our example, we used ProtectNetwork.org as our IDP. We had to edit two files, /etc/myproxy/grid-mapfile and /etc/httpd/conf.d/shib2.conf.

We added the identities from the IDP to our grid-mapfile so that the users would be allowed to log in.

"/CN=wayward" wayward@idp.protectnetwork.org
"/CN=jbasney" jbasney@idp.protectnetwork.org

Below is what we added to our shib2.conf file to protect the Oauth4MP location.

<Location /oauth/authorize>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  ShibUseHeaders On
  require valid-user
</Location>

Authentication with Tomcat

There are many ways to configure Tomcat authentication. For the purpose of this documentation, we’ll illustrate basic authentication, which is the simplest method.

Edit the $CATALINA_HOME/conf/tomcat-users.xml file and the file in $CATALINA_HOME/webapps/oauth/WEB-INF/web.xml . (Not the same web.xml file as in the main Tomcat conf directory).

This is what we added to tomcat-users.xml

  <role rolename="testuser"/>
  <user username="testuser1" password="testpassword1" roles="testuser"/>
  <user username="testuser2" password="testpassword2" roles="testuser"/> 

This is what we added to the web.xml file

<security-constraint>
  <web-resource-collection> 
    <web-resource-name>OAuth Security</web-resource-name> 
    <url-pattern>/authorize</url-pattern> 
    <http-method>POST</http-method> 
    <http-method>GET</http-method> 
  </web-resource-collection> 
  <auth-constraint> 
    <role-name>oa4mp</role-name> 
  </auth-constraint> 
  <user-data-constraint> 
  <!-- transport-guarantee can be CONFIDENTIAL, INTEGRAL, or NONE --> 
  <transport-guarantee>NONE</transport-guarantee> 
  </user-data-constraint> 
</security-constraint> 
<login-config> 
<auth-method>BASIC</auth-method> 
</login-config>

Nota Bene: This enables remote user for the authorize endpoint. If you wanted to use this for the device endpoint, you would have another set the url-pattern accordingly to

    <url-pattern>/device</url-pattern>

Note that redeploying OA4MP (e.g., a fresh version) may overwrite the web.xml file, so we recommend backing it up somewhere secure.

Troubleshooting

"Error: configuration required using the header "REMOTE_USER" but this was not set. Cannot continue."

This means that the security-constraint in the web.xml file is somehow not correct.

MyProxy

Attempt to connect to MyProxy server directly. You can do this using myproxy-logon. The GUI is documented at http://grid.ncsa.illinois.edu/myproxy/MyProxyLogon/ . The command line option is documented at http://grid.ncsa.illinois.edu/myproxy/man/myproxy-logon.1.html . Note that you will need to execute the command as root, e.g. "sudo myproxy-logon -s test.server.com."

Make sure that the serial, grid-mapfile, and certificate files have the appropriate permissions and ownership. On shibber, they are owned by "myproxy." If myproxy can’t read the files, it will fail.

The value in the serial file should be an integer, and the file needs to be writeable by myproxy.

Make sure that certificate_issuer_cert and certificate_issuer_key in the myproxy-server.config file point to valid locations and the certificate is current (not expired).

Configuration

Check firewall configuration on both client and servers. Is it permitting outside connections on the ports that OA4MP is using?

Did the client approval page use the appropriate port? If the application is using port 8443, the client approval needs to be for that port. Likewise, if it's using the default port 80, the client approval also needs to correspond to that.

Apache

Does your password file you are using have appropriate permissions, e.g. readable by Apache?

Is your Apache certificate trusted by your Tomcat installation? Self-signed certs generally are not.

Tomcat

Make sure you’ve told Tomcat to trust your keystore when starting. You can do this by setting CATALINA_OPTS, e.g.

export CATALINA_OPTS="-Djavax.net.ssl.trustStore=$HOME/oa4mp/cacerts.jks"

General

Make sure you don’t have both Apache and Tomcat authentication enabled at the same time.

Check log files - OA4MP often uses delegation.xml in the OA4MP directory or somewhere in the Tomcat path (bin and/or logs directory). You might also look at the Tomcat log file, which is usually called "catalina.out", the Apache logs, and the system logs. Note: the catalina.out file is likely to contain more information than the localhostXXXX-XX-XX.log files.