Master Portal Administrator Guide

Introduction

The Master Portal is a central component in the AARC Piloting work. The Master Portal caches long lived user proxies into its Credential Store, and returns short lived proxies on demand to a trusted portal (Science Gateway) for authenticated users. This page is dedicated for Master Portal operators and administrators who wish to configure their Master Portals.

Credential Store Configuration

The Master Portal cannot be operated without its Credential Store. Missing the Credential Store from your setup will render your Master Portal unable to cache and retrieve any proxy certificates. Without the Credential Store a Master Portal can still be used for user authentication (via OIDC), but it's GetProxy Endpoint will be unable to retrieve proxy certificates.

MyProxy Server

The Credential Store is nothing else than a simple MyProxy Server installation running in Credential Store mode. It being an unmodified MyProxy Server, you can tailor its configuration to your needs following the official MyProxy Server admin guide. In order to run it as a Credential Store backend for the Master Portal, you will need the following set of configurations:

accepted_credentials            <Master Portal Host DN>
authorized_retrievers           <Master Portal Host DN>
authorized_renewers             <Master Portal Host DN>
default_authorized_renewers     <Master Portal Host DN>
trusted_retrievers              <Master Portal Host DN>

cert_dir                        /etc/grid-security/certificates
max_proxy_lifetime              264

The Master Portal authenticates to the MyProxy Server via its host certificates. Make sure to configure the DN of the host certificate of the Master Portal (<Master Portal Host DN>) as the authorized party in the MyProxy Server configuration snippet above. If you are interested to see what each of those individual authrizations stand for please consult the man page of myproxy-server.config. The cert_dir has to point to the set of trust roots trusted by the MyProxy Server. The max_proxy_lifetime determines the maximum lifetime in hours that a returned proxy credential can have. Since the Master Portal is only allowed to release short lived proxy certificates, a lifetime of 264 hours (11 days) is imposed by default. The MyProxy Server will be able to release proxies with shorter lifetime on demand, but not with bigger lifetime than that of max_proxy_lifetime.

VOMS Support

The MyProxy Server returns returns non-vomsified proxies by default, but it has support for releasing VOMS-ified proxies as well. Asking for VOMS-ified proxies is also supported in the Master Portal via the GetProxy Endpoint. In order to enable VOMS support in the MyProxy Server, set allow_voms_attribute_requests

allow_voms_attribute_requests   True

Self-Authorized Rertieval

The MyProxy Server disallows self renewal of certificates by default, but this function can be enabled. By enabling this, users possessing a valid proxy certificate will be able to renew it (prolong its lifetime) by directly talking to the MyProxy Server, and without the intervention of any of the web components (such as the Master Portal). This setup is still experimental and it does not affect the delegation scenario involving the Master Portal, therefore it is safe to unset when not needed.

authorized_renewers             "/DC=NL/DC=Example/O=*"
allow_self_authorization        True

In the above configuration snippet the authorized_renewers should contain a "DN regex". This regex should be the common bit of the DNs of the proxy certificates stored in the MyProxy Server. This configuration will NOT allow users to renew other user's credentials, because there are per-credential policies in place that restricts the access of a single proxy certificate to it's own full "DN regex". These policies are added to each credential during their upload by the Master Portal.

Trust Root

Deploying the trust root of the Online CA (see Online CA of detailed achitecture) is an important step. Make sure to deploy this trust root in the directory pointed by the cert_dir above, otherwise the MyProxy Server will not accept the generated user proxies the Master Portal will try to upload in its store. Make sure that the trust root has its signing policy, crl, and subject hash links in order.

Extras

Purge Script

The MyProxy Server doesn't remove expired or revoked credentials. The Master Portal can detect if a proxy certificate stored in the MyProxy Server is expired and it can replace it with a new one, but it cannot detect revoked certificates. Because of this, it can happen that the MyProxy Server can contain expired or revoked certificates. In order to account for this (mostly because a revoked certificate poses a threat) we developed a script called myproxy-purge.sh. The myproxy-purge.sh script is periodically called by a cron job to check every proxy certificate stored in the MyProxy Server and remove the ones that have expired or have been revoked. By default this script is called every 6 hours. You can change this frequency by editing /etc/cron.d/myproxy_purge.

Master Portal Configuration

The Master Portal is made up internally of a OA4MP Server and Client, just as described here. Both OA4MP Server and Client are web applications packaged in .war files. In order to deploy these you will need a web container. The setup used for this includes Tomcat as the web container (following the suggestions given by OA4MP Server), with an Apache httpd server running in front of the web container, acting as a reverse https proxy. 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 Master Portal 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 for both MP Client and Server to pass through. For a list of valid endpoints on the Master Portal, you can consult this page. Your configuration should contain something like the following:

ProxyPass /mp-oa2-server/authorized !
ProxyPass /mp-oa2-server ajp://127.0.0.1:8009/mp-oa2-server

ProxyPass /mp-oa2-client/forwardgetcert !
ProxyPass /mp-oa2-client/startRequest !
ProxyPass /mp-oa2-client ajp://127.0.0.1:8009/mp-oa2-client

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 Master Portal. Make sure to define proxy rules in order of precedence from most restrictive to least restrictive!

Tomcat

In the Tomcat server.xml configuration make sure to have the AJP connector opened on port 8009. There are a couple of restrictions you should enable on this connector:

• Setting address="127.0.0.1" will enforce local access only on the container. Without this a user could bypass the Apache server (and authentication) by directly accessing port 8009 from the browser. This should not be possible due to firewall restrictions in the first place, but even if the firewall fails, this configuration will still keep out any access not coming from localhost.
• Setting tomcatAuthentication="false" will tell Tomcat to trust the external authenticator (Apache).

<Connector port="8009" address="127.0.0.1" tomcatAuthentication="false" protocol="AJP/1.3"/>

Since the Master Portal is made up of two separate components, a MP Server and Client , they run as two independent web applications inside the web container. In order to be able to forward requests internally between the two (without going through the browser) the crossContext flag has to be enabled in context.xml. This will allow all web application to get access to each other, within the container.

<Context crossContext="true">     
...
</Context>

MP Client Config

• DB tables

• oa4mp server config

• oa4mp client config