Master Portal Administrator Guide
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.
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.
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
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.
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.
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 packages in a .war file. In order to deploy these you will need a web container. The setup used for this include 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 how this setup works can be found here and here.
- mod_ssl (list of endpoints enabled)
- tomcat cross context , disable tomcat_auth, set listening address
MP Server Config
MP Client Config
- DB tables
- oa4mp server config
- oa4mp client config