Since version 0.3.0 the GridShib-CA allows for the delegation of a Grid credential based on Shibboleth authentication of the user to a web portal that is not itself Shibboleth enabled.
Note that this functionality is highly experimental and disabled by default. To enabled this functionality the parameter allowPortalDelegation must be set to "True". (See the configuration directions in the installation guide for details.)
In addition to the user being authorized, the portal must also be authorized to receive credentials
An example portal can be found here (and its source can be found here)
The portal must meet the following requirements:
It must be https protected.
It must be able to generate a key pair and certificate request
It must authenticate the user and save state from the generation of the certificate request to when the certificate is returned.
 |
User visits application portal. Portal creates a key pair and certificate request for the user and presents a user with a form to submit the certificate request to the GridShib-CA. The form should have the following fields:
certificateRequest: The PEM-encoded PKCS10 certificate request
portalURL: The URL to which the generated certificate should be posted in step 6. This URL must be https.
portData: Arbitrary data which will be returned to the portal in step 6.
User submits form generated by application portal, submitting certificate request to the GridShib-CA. This will cause the user to undergo Shibboleth authentication if they have not already done so. The portalLogin.cgi script will present the user with a form indicating that they are about to delegation a Grid credential to the portal and ask them to confirm. This form will have all the fields listed in the previous step, plus the following:
token: A encrypted token that ensures the users has agreed to this delegation. This prevents the users from being directed to the GridShib-CA by a malicious portal.
When the user submits the form from portalLogin.cgi, the certificate request will be submitted to generateCred.cgi.
Assuming the user and portal are authorized a certificate will be created.
The certificate is presented back to the user to submit back to the portal. The presented form will have tje following variables:
status: One of the following possible values: success or rejected. rejected indicates that the user declined to delegate a credential.
certificate: The PEM-encoded X.509 certificate.
portalData: The portal data from step 1.
When the user submits the certificate back to the portal, the portal associates the certificate with the key pair it previously generated, creating a Grid credential to be used on behalf of the user. Not that the portal should be aware that a malicious user could alter fields presented and validate things accordingly. In particular the portal should ensure the modulus of the returned certificate matches the modulus in the private key generated in step 1. It should also be wary trusting the information in portalData - this can be used to help it complete the request, but should not be trusted in its own right.