Difference between revisions of "Delegation Server Administrator Guide"

From PDP/Grid Wiki
Jump to navigationJump to search
(ds config structure)
 
(intro + apache)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
 +
 +
The Delegation Server is a key component in the [[AARC_Pilot | AARC Piloting]] work. The Delegation Server issues certificates for authenticated users based on their released attributes. Our current Delegation Server implementation is called [[AARC_Pilot_-_RCAuth.eu | RCAuth.eu]]. This page is dedicated for Delegation Server operators and administrators who wish to fine tune their server.
 +
 +
In case you want to '''deploy''' the Delegation Server, make sure to check out our [[AARC_Pilot_-_Building_from_Source#Building_the_Delegation_Server | guide]] on using Ansible deployment scripts. Most of the presented configuration from below are set by the Ansible scripts.
  
 
= Delegation Server Configuration =
 
= Delegation Server Configuration =
 +
 +
The Delegation Server is a web application packaged in a .war file, based on the [http://grid.ncsa.illinois.edu/myproxy/oauth/server/index.xhtml OA4MP Server]. In order to deploy it you will need a web container. The setup used for this includes [https://tomcat.apache.org/tomcat-7.0-doc/index.html Tomcat] as the web container (following the suggestions given by the [http://grid.ncsa.illinois.edu/myproxy/oauth/server/manuals/getting-started.xhtml OA4MP Server]), with an [https://httpd.apache.org/ Apache] httpd server running in front of the web container, acting as a reverse https proxy, and authenticating users through [https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig mod_shib]. Details on the reverse proxy setup can be found [https://tomcat.apache.org/tomcat-7.0-doc/proxy-howto.html here] and [http://grid.ncsa.illinois.edu/myproxy/oauth/server/manuals/getting-started.xhtml here].
  
 
== Apache ==
 
== Apache ==
 +
 +
The Apache server holds configurations relating to the SSL setup of the Delegation Server and to the proxy setup talking to Tomcat. In case you want to tweak either of these options, you should look into '''/etc/httpd/conf.d/ssl.conf'''. Make sure to configure the [https://httpd.apache.org/docs/current/mod/mod_proxy.html mod_proxy] setting to allow the Delegation Server to pass through. Your configuration should contain something like the following:
 +
 +
ProxyPass /oauth2/authorized !
 +
ProxyPass /oauth2 ajp://127.0.0.1:8009/oauth2
 +
 +
'''Note!''' Take special care to disallow the /authorized endpoint to be forwarded, since it's a [http://grid.ncsa.illinois.edu/myproxy/oauth/server/manuals/authorized.xhtml private endpoint] meant only to be called from within the server. Make sure to define proxy rules in order of precedence from most restrictive to least restrictive!
 +
 +
Inside the apache configuration '''/etc/httpd/conf.d/shib.conf''' you should make sure to protect the authorization endpoint of the Delegation Server to be only reachable to authenticated users. It is also a good idea to protect the /register (client self-registration) endpoint, in order to avoid the Delegation Server getting flooded with self-registration requests.
 +
 +
<Location /oauth2/authorize>
 +
  AuthType shibboleth
 +
  ShibRequestSetting requireSession 1
 +
  ShibRequestSetting exportAssertion true
 +
  ShibUseHeaders On
 +
  Require valid-user
 +
</Location>
 +
 +
<Location /oauth2/register>
 +
  AuthType shibboleth
 +
  ShibRequestSetting requireSession 1
 +
  ShibUseHeaders On
 +
  Require valid-user
 +
</Location>
 +
 +
Take a look at the [https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig mod_shib] documentation to see what the above options all mean.
 +
 +
'''Note!''' Beware of the [https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking spoofing voulnerability] which occurs when using '''ShibUseHeaders''' as a means of releasing attributes to the web application. Currently OA4MP Server expects attributes through the use of headers, but as soon as it moves away from it, '''ShibUseHeaders''' should be exchanged it's alternative: '''ShibUseEnvironment'''.
  
 
== Tomcat ==
 
== Tomcat ==

Revision as of 14:18, 24 August 2016

Introduction

The Delegation Server is a key component in the AARC Piloting work. The Delegation Server issues certificates for authenticated users based on their released attributes. Our current Delegation Server implementation is called RCAuth.eu. This page is dedicated for Delegation Server operators and administrators who wish to fine tune their server.

In case you want to deploy the Delegation Server, make sure to check out our guide on using Ansible deployment scripts. Most of the presented configuration from below are set by the Ansible scripts.

Delegation Server Configuration

The Delegation Server is a web application packaged in a .war file, based on the OA4MP Server. In order to deploy it you will need a web container. The setup used for this includes Tomcat as the web container (following the suggestions given by the OA4MP Server), with an Apache httpd server running in front of the web container, acting as a reverse https proxy, and authenticating users through mod_shib. Details on the reverse proxy setup can be found here and here.

Apache

The Apache server holds configurations relating to the SSL setup of the Delegation Server and to the proxy setup talking to Tomcat. In case you want to tweak either of these options, you should look into /etc/httpd/conf.d/ssl.conf. Make sure to configure the mod_proxy setting to allow the Delegation Server to pass through. Your configuration should contain something like the following:

ProxyPass /oauth2/authorized !
ProxyPass /oauth2 ajp://127.0.0.1:8009/oauth2

Note! Take special care to disallow the /authorized endpoint to be forwarded, since it's a private endpoint meant only to be called from within the server. Make sure to define proxy rules in order of precedence from most restrictive to least restrictive!

Inside the apache configuration /etc/httpd/conf.d/shib.conf you should make sure to protect the authorization endpoint of the Delegation Server to be only reachable to authenticated users. It is also a good idea to protect the /register (client self-registration) endpoint, in order to avoid the Delegation Server getting flooded with self-registration requests.

<Location /oauth2/authorize>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  ShibRequestSetting exportAssertion true
  ShibUseHeaders On
  Require valid-user
</Location>

<Location /oauth2/register>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  ShibUseHeaders On
  Require valid-user
</Location>

Take a look at the mod_shib documentation to see what the above options all mean.

Note! Beware of the spoofing voulnerability which occurs when using ShibUseHeaders as a means of releasing attributes to the web application. Currently OA4MP Server expects attributes through the use of headers, but as soon as it moves away from it, ShibUseHeaders should be exchanged it's alternative: ShibUseEnvironment.

Tomcat

Shibboleth

Delegation Server

Configuration

Database

CLI

Logs