Difference between revisions of "RCauth.eu and MasterPortal architecture"
(fixed AARC Pilot - Building from Source links)
(changed github links to RCauth.eu organization)
|Line 115:||Line 115:|
== Sources ==
== Sources ==
The sources for the Master Portal and the VO Portal can be found on [https://github.com/
The sources for the Master Portal and the VO Portal can be found on [https://github.com/-github]. In order to build them you first have to make sure that the two dependency projects [https://github.com//myproxy-fork myproxy-fork] and [https://github.com//ncsa-security-all-fork ncsa-security-all-fork] are build and installed in the local maven repository. Check out the 'devel' branch of each dependency and build them in the following order: first '''ncsa-security-all-fork''', then '''myproxy-fork'''.
== GetProxy Endpoint ==
== GetProxy Endpoint ==
Revision as of 14:20, 17 August 2016
Introducing the Master Portal
- interface with VOMS as an attribute provider and retrieve vomsified proxies.
- design a scalable setup which takes off some of the load of the main certificate issuing component.
High Level Architecture
- the yellow services (bottom right box) are the central (European-wide?) CILogon/Online CA services.
- the red services (center box) are the myproxy credential store plus its frontend services: master portal, ssh server plus the needed extra services. There could be multiple, e.g. one per federation, effectively different OpenID Connect clients.
- the blue services (left box) are run by the VO
- the green services are e.g. Grid UIs but could also be CEs or laptops and are using non-web 'SSO'.
- the purple service is the IdP.
Here we describe a brief overview of the flow through which users create and retrieve a voms proxy. A detailed explanation will follow later.
1) user enters via very-light-weight VO Portal on the left, specifying something such as requested VOMS FQANs.
2) VO Portal redirects to Master Portal which is a customized CILogon portal doing the CILogin portal delegation. The next few steps are the standard portal delegation also described above
3a) redirect to Delegation Service.
3b) Delegation Service sends to WAYF and IdP
3c) return (few steps) to Delegation Service which returns OAuth token to Master Portal
3d) Master Portal uses token to send a request to /userinfo to get user's identity.
When there is no valid certificate in the MyProxy Credential Store step 4) will be done
4a) Master Portal sends CSR and obtains certificate+key. The remaining steps are not part of standard CILogon/OA4MP.
4b) Master Portal will store the cert+key into a seconds myproxy server (MyProxy Credential Store) with the obtained identity. The myproxy server uses server-side VOMS integration.
5) Master Portal can now use jGlobus' myproxy API to obtain vomsified proxies from this MyProxy Credential Store, where it will be a trusted retriever. It will send those back (on demand) to the VO portal. When the user asked for invalid VOMS credentials, this will also be fed back to the user.
The next two steps are an extension to enable access on e.g. workernodes or UIs. i.e. non-web 'sso'. It's quite similar to what github is doing.
7) Master Portal allows uploading of ssh public keys which are put in the authorized keys file on SSH Server.
8) When the user logs in onto the SSH Server it will automatically (using the command option in the authorized keys file) run a script which will run something like a myproxy-get-delegation and return a short-lived proxy to the user via e.g. stdout over the ssh. We can probably use the myproxy-server-side voms for that, by passing the right information to the SSH server, alternatively the user or the script can do that on client side.
As an alternative way of accessing a user proxy from the command line with user credentials (username and password) the Master portal can do the following:
7) provision a custom account in for example an LDAP server, belonging to the user, where the user picks a password. Other methods are possible too, as long as they are compatible with PAM.
8) This can then be used by the user to authenticate using PAM against the MyProxy Credential Store to retrieve a short-lived proxy. In this case, it is probably necessary to do the vomsification on client side.
There is a public instance of the setup described above living in Okeanos. You can start the flow of receiving a voms proxy by navigating to the VO Portal. The public demo works with the SURFconext Test Instance to showcase the integration with an identity federation. You will have to log in with one of the test professor accounts. Please note, that this setup is still under development, therefore it is subject to frequent changes.
- user browses to VO portal
- redirect to /authorize on Master Portal (OIDC1)
- redirect to /authorize on DS (OIDC2)
- redirect to WAYF (SAML)
- redirect to IdP (SAML) -> user logs in
- redirect back to /authorize on DS (SAML)
- redirect to redirect_uri on Master Portal (/ready endpoint) (OIDC2)
(Master portal retrieves access_token2 and userinfo)
- redirect back to redirect_uri on VO portal (OIDC1)
Next steps are all hidden for the end-user.
- VO portal retrieves access_token1
- VO portal retrieves userinfo from Master Portal using access_token1
- VO portal calls /getproxy endpoint on Master Portal using access_token1, optionally with VOMSES and VOMS string
- Master Portal does INFO on MyProxy credstore to check for long-lived proxy:
no proxy yet:
- Master Portal creates keypair + CSR
- Master Portal calls /getcert on DS using access_token2 and CSR
- DS does a MyProxy GET request at online CA, using the CSR
- online CA signs the CSR and returns the end-entity certificate to the DS
DS returns end-entity certificate to Master Portal
Master Portal uses end-entity certificate and key to delegate (MyProxy PUT) a long-lived proxy to MyProxy credstore
- Master Portal retrieves short lived (VOMS) proxy from MyProxy credstore
- Master Portal returns proxy to VO portal
The sources for the Master Portal and the VO Portal can be found on github. In order to build them you first have to make sure that the two dependency projects myproxy-fork and ncsa-security-all-fork are build and installed in the local maven repository. Check out the 'devel' branch of each dependency and build them in the following order: first ncsa-security-all-fork, then myproxy-fork.
In order to retrieve proxies instead of end entity certificates from the Master Portal we proposed an extension to the OIDC/OA4MP Protocol. This is called the OAuth for MyProxy GetProxy Endpoint extension.
Building and Deploying
If you want to build any of the software components described above (VO Portal, Master Portal, Delegation Server), please refer to this guide detailing the build procedure. If you are looking for a deployment guide for the setup described above, check out the Ansible scripts (previously, we also provided deployment scripts using Jenkins but this is has been obsoleted by the Ansible scirpts).