GridShib for Globus Toolkit
Version 0.6.0 Technology Preview 4
July 30, 2007

A lightweight alternative to installing the full Globus Toolkit (GT) is to only install the Java WS Core component of GT4, and then install GridShib for GT on top of that. In fact, this is the only option under Windows, which does not support the full Globus Toolkit, so the following guide shows how to layer GridShib for GT on top of Java WS Core.

This "Quick Start" guide gives detailed instructions for installing, configuring, and using Java WS Core 4.0.5, GridShib for GT v0.6.0, and GridShib SAML Tools v0.2.0. This software stack will run on a wide variety of platforms, including Windows. Software requirements include JDK 1.4.2 (or higher) and Ant 1.6 (or higher), which we assume are already installed on the platform of choice.

Like the Globus Toolkit Quick Start guide, the following Quick Start will show how to install and configure the software on two systems, which we call local host and remote host. In addition to the general software requirements mentioned above, we assume local host has Java Web Start installed so that we can leverage the GridShib CA to obtain credentials. Please check for Java Web Start on local host before continuing.

For the purposes of this Quick Start, we will assume that local host is a Windows system while remote host is a UNIX system. Other platform combinations are possible of course.

Contents

Install JWS Core on local host

  1. Install the binary version of Java WS Core 4.0.5 on Windows.
    The binary version of Java WS Core is simplest, but of course the source version works just as well.
    1. Extract the ZIP archive to any folder on your hard drive (say, c:\globus).
    2. Open a Command Prompt window, change directory to the installation directory, and set the GLOBUS_LOCATION environment variable (which is case sensitive, even on Windows in this case): 
      > cd c:\globus\ws-core-4.0.5-bin\ws-core-4.0.5
> set GLOBUS_LOCATION=%CD%
> echo %GLOBUS_LOCATION%
    3. For debugging purposes, add the following line to %GLOBUS_LOCATION%\container-log4j.properties: 
      log4j.category.org.globus.gridshib.gt=DEBUG
    4. As a crude test, start the container (with transport-level security disabled): 
      > bin\globus-start-container -nosec
Starting SOAP server at: http://141.142.251.212:8080/wsrf/services/
With the following services:

[1]: http://141.142.251.212:8080/wsrf/services/AdminService
[2]: http://141.142.251.212:8080/wsrf/services/AuthzCalloutTestService
[3]: http://141.142.251.212:8080/wsrf/services/ContainerRegistryEntryService
[4]: http://141.142.251.212:8080/wsrf/services/ContainerRegistryService
[5]: http://141.142.251.212:8080/wsrf/services/CounterService
[6]: http://141.142.251.212:8080/wsrf/services/ManagementService
[7]: http://141.142.251.212:8080/wsrf/services/NotificationConsumerFactoryService
[8]: http://141.142.251.212:8080/wsrf/services/NotificationConsumerService
[9]: http://141.142.251.212:8080/wsrf/services/NotificationTestService
[10]: http://141.142.251.212:8080/wsrf/services/PersistenceTestSubscriptionManager
[11]: http://141.142.251.212:8080/wsrf/services/SampleAuthzService
[12]: http://141.142.251.212:8080/wsrf/services/SecureCounterService
[13]: http://141.142.251.212:8080/wsrf/services/SecurityTestService
[14]: http://141.142.251.212:8080/wsrf/services/ShutdownService
[15]: http://141.142.251.212:8080/wsrf/services/SubscriptionManagerService
[16]: http://141.142.251.212:8080/wsrf/services/TestAuthzService
[17]: http://141.142.251.212:8080/wsrf/services/TestRPCService
[18]: http://141.142.251.212:8080/wsrf/services/TestService
[19]: http://141.142.251.212:8080/wsrf/services/TestServiceRequest
[20]: http://141.142.251.212:8080/wsrf/services/TestServiceWrongWSDL
[21]: http://141.142.251.212:8080/wsrf/services/Version
[22]: http://141.142.251.212:8080/wsrf/services/WidgetNotificationService
[23]: http://141.142.251.212:8080/wsrf/services/WidgetService
[24]: http://141.142.251.212:8080/wsrf/services/gsi/AuthenticationService
      Press Ctrl-C to abort the container.
  2. Install a trusted certificate.
    In what follows, we will use a GridShib CA-issued end-entity certificate (EEC) to authenticate to GT services. We will also issue proxy certificates using a GridShib CA-issued EEC. Thus the container needs to be configured to trust certificates issued by the GridShib CA.
    1. Download the public certificate of the GridShib CA.
    2. Extract the ZIP archive to folder "%USERPROFILE%\.globus\certificates". Verify the trusted certificate was extracted to the trusted certificate directory: 
      > dir "%USERPROFILE%\.globus\certificates"
...
02/19/2007  10:15 PM             1,667 bfcd1f28.0
02/19/2007  10:15 PM               239 bfcd1f28.signing_policy
  3. Obtain a user certificate and stop the container normally.
    Ironically, it is more difficult to stop a container with transport security disabled (-nosec) than to stop a secure container.
    1. In the previous Command Prompt window, start the container again: 
      > echo %GLOBUS_LOCATION%
> bin\globus-start-container -nosec
Starting SOAP server at: http://141.142.251.212:8080/wsrf/services/
With the following services...
    2. Open another Command Prompt window and try to stop the container: 
      > cd c:\globus\ws-core-4.0.5-bin\ws-core-4.0.5
> set GLOBUS_LOCATION=%CD%
> echo %GLOBUS_LOCATION%
> bin\globus-stop-container -s http://localhost:8080/wsrf/services/ShutdownService
Error: ; nested exception is:
GSSException: Defective credential detected [Caused by:
Proxy file (C:\DOCUME~1\TOMSCA~1\LOCALS~1\Temp\x509up_u_tom scavo) not found.]
    3. Press Ctrl-C to abort the container.
    4. Obtain a short-term X.509 end-entity credential from the online GridShib CA.
    5. In the first Command Prompt window, start the container as before.
    6. In the second Command Prompt window, try to stop the container again: 
      > bin\globus-stop-container -s http://localhost:8080/wsrf/services/ShutdownService
Error: ; nested exception is:
java.net.ConnectException: Connection refused: connect
    7. Finally, stop the container normally, authenticating with your GridShib CA-issued credential via Secure Message: 
      > bin\globus-stop-container -s http://localhost:8080/wsrf/services/ShutdownService -m msg
  4. Start and stop a secure container.
    For the rest of this tutorial, we require a secure container.
    1. In the first Command Prompt window, start the container: 
      > echo %GLOBUS_LOCATION%
> bin\globus-start-container
Starting SOAP server at: https://141.142.250.163:8443/wsrf/services/
With the following services...
    2. In the second Command Prompt window, stop the container: 
      > echo %GLOBUS_LOCATION%
> bin\globus-stop-container
  5. Request the SecureCounterService, authenticating with your EEC via Secure Conversation.
    1. In the first Command Prompt window, start the container: 
      > echo %GLOBUS_LOCATION%
> bin\globus-start-container
Starting SOAP server at: https://141.142.250.163:8443/wsrf/services/
With the following services...
    2. In the second Command Prompt window, request a service: 
      > echo %GLOBUS_LOCATION%
> bin\counter-client -m conv -z none
    -s https://localhost:8443/wsrf/services/SecureCounterService
Got notification with value: 3
Counter has value: 3
Got notification with value: 13
    3. In the second Command Prompt window, stop the container: 
      > bin\globus-stop-container

Install GridShib for GT on local host

  1. Before installing this version of GridShib for GT, be sure to uninstall any previous versions that may have been installed in GLOBUS_LOCATION.
    1. In the second Command Prompt window, type the following commands: 
      > cd c:\gridshib\gridshib-gt-X_X_X-src\gridshib-gt-X_X_X
> echo %GLOBUS_LOCATION%
> ant undeploy
> ant undeploy-echoservice
> ant undeploy-tests
  2. Install GridShib for GT v0.6.0 on Windows.
    1. Download the GS4GT v0.6.0 source distribution (ZIP archive) from the GridShib web site. (A GZIP archive is also available for UNIX users.)
    2. Double-click the ZIP archive and extract the source files into a folder of your choice (say, c:\gridshib).
    3. In the second Command Prompt window, type the following commands: 
      > cd c:\gridshib\gridshib-gt-0_6_0-src\gridshib-gt-0_6_0
> echo %GLOBUS_LOCATION%
> ant deploy
> ant deploy-echoservice
  3. Request the SecurityContextEchoService, authenticating with your EEC.
    An EEC obtained from the GridShib CA contains a bound SAML assertion with no attributes. Thus you will see one "identity" in the logs, namely, the value of the NameIdentifier element in the bound assertion.
    1. In the first Command Prompt window, start the container: 
      > echo %GLOBUS_LOCATION%
> bin\globus-start-container
Starting SOAP server at: https://141.142.250.163:8443/wsrf/services/
With the following services...
    2. In the second Command Prompt window, copy your EEC to a preconfigured location (say, c:\temp\testcredential.pem), set your environment, and request the service: 
      > copy "%TEMP%\x509up_u_%USERNAME%" c:\temp\testcredential.pem
> set X509_USER_PROXY=c:\temp\testcredential.pem
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
---------
Response:
---------

SAMLIdentity {
  issuer='https://test-sp.ncsa.uiuc.edu/shibboleth'
  nameID='<NameIdentifier
             xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
             xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
             xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
             xmlns:samlsap="urn:oasis:names:tc:SAML:1.1:profiles:assertion:subject"
             xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
             CN=trscavo@openidp.org,OU=urn:mace:inqueue:shib13.openidp.org,
             O=Shibboleth User,DC=computer,DC=ncsa,DC=uiuc,DC=edu</NameIdentifier>'
}
Principal {
  name='/DC=edu/DC=uiuc/DC=ncsa/DC=computer/O=Shibboleth User
        /OU=urn:mace:inqueue:shib13.openidp.org
        /CN=trscavo@openidp.org'
}
    3. In the second Command Prompt window, stop the container.

Install GridShib SAML Tools on local host

  1. Install GridShib SAML Tools v0.2.0 on Windows.
    To install the GridShib SAML Tools, we invoke an ant script that creates a JAR file and runs some tests. The tests use a default issuing credential bundled with the SAML Tools.
    1. Download the GridShib SAML Tools v0.2.0 source distribution (ZIP archive) from the GridShib web site. (A GZIP archive is also available for UNIX users.)
    2. Double-click the ZIP archive and extract the source files into a folder of your choice (say, c:\gridshib).
    3. In the second Command Prompt window, type the following commands: 
      > cd c:\gridshib\gridshib-saml-0_2_0-src\gridshib-saml-0_2_0
> set GRIDSHIB_HOME=%CD%
> ant install
      See the Installation Notes for more information about GridShib SAML Tools.
  2. Configure GridShib SAML Tools v0.2.0 on Windows.
    We will configure the SAML Tools to sign proxy certificates using your GridShib CA-issued EEC. So that GridShib for GT recognizes the issuer of the embedded SAML assertion, we will also set the IDPEntityID property to the Subject DN of your EEC.
    1. Uncomment the following lines in %GRIDSHIB_HOME%\etc\gridshib\tools\gridshib-saml-issuer.properties: 
      certLocation=file:/%TEMP%/x509up_u_%USERNAME%
keyLocation=file:/%TEMP%/x509up_u_%USERNAME%
      Replace the placeholders %TEMP% and %USERNAME% with their actual values, changing the backslashes to forward slashes for proper URL syntax.
  3. Request the SecurityContextEchoService, authenticating with a level 1 proxy credential.
    Since the GridShib SAML Tools issue and bind a SAML assertion to the certificate (like the GridShib CA), the output from the SecurityContextEchoService will be the combined security information from both the GridShib CA-issued EEC and the proxy certificate.
    1. In the second Command Prompt window, issue a level 1 proxy: 
      > %GRIDSHIB_HOME%\bin\gridshib-saml-issuer --user trscavo
    --authn --x509 --outfile c:\temp\testcredential.pem
    --authnMethod urn:oasis:names:tc:SAML:1.0:am:password
    2. In the first Command Prompt window, start the container.
    3. In the second Command Prompt window, set the proxy path and request the service: 
      > set X509_USER_PROXY=c:\temp\testcredential.pem
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
---------
Response:
---------

SAMLIdentity {
  issuer='CN=trscavo@openidp.org,
          OU=urn:mace:inqueue:shib13.openidp.org,O=Shibboleth User,
          DC=computer,DC=ncsa,DC=uiuc,DC=edu'
  nameID='<NameIdentifier
            xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
            xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
            xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
            trscavo</NameIdentifier>'
}
SAMLIdentity {
  issuer='https://test-sp.ncsa.uiuc.edu/shibboleth'
  nameID='<NameIdentifier
            xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
            xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
            xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
            xmlns:samlsap="urn:oasis:names:tc:SAML:1.1:profiles:assertion:subject"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
            CN=trscavo@openidp.org,OU=urn:mace:inqueue:shib13.openidp.org,
            O=Shibboleth User,DC=computer,DC=ncsa,DC=uiuc,DC=edu</NameIdentifier>'
}
SAMLAuthnContext {
  issuer='CN=trscavo@openidp.org,
          OU=urn:mace:inqueue:shib13.openidp.org,O=Shibboleth User,
          DC=computer,DC=ncsa,DC=uiuc,DC=edu'
  authnMethod='urn:oasis:names:tc:SAML:1.0:am:password'
  authnInstant='2007-07-27T13:24:34Z'
  ipAddress='null'
  dnsName='null'
}
(raw) BasicAttribute {
  issuer='CN=trscavo@openidp.org,
          OU=urn:mace:inqueue:shib13.openidp.org,O=Shibboleth User,
          DC=computer,DC=ncsa,DC=uiuc,DC=edu'
  name='urn:oid:2.5.4.6'
  nameFormat='urn:mace:shibboleth:1.0:attributeNamespace:uri'
  value #1='US'
}
(raw) BasicAttribute {
  issuer='CN=trscavo@openidp.org,
          OU=urn:mace:inqueue:shib13.openidp.org,O=Shibboleth User,
          DC=computer,DC=ncsa,DC=uiuc,DC=edu'
  name='urn:oid:1.3.6.1.4.1.5923.1.5.1.1'
  nameFormat='urn:mace:shibboleth:1.0:attributeNamespace:uri'
  value #1='http://www.nanohub.org'
}
Principal {
  name='/DC=edu/DC=uiuc/DC=ncsa/DC=computer/O=Shibboleth User/
         OU=urn:mace:inqueue:shib13.openidp.org/CN=trscavo@openidp.org'
}
      As you can see, there are a total of six (6) items in the above response:
      • Two (2) SAMLIdentity items, corresponding to the NameIdentifier elements in the bound SAML assertions
      • One (1) SAMLAuthnContext item, corresponding to the SAMLAuthenticationStatement element in the SAML assertion bound to the proxy certificate
      • Two (2) BasicAttribute items, corresponding to the SAMLAttribute elements bound to the proxy certificate
      • One (1) Principal item, the Subject DN of your GridShib CA-issued EEC
      You will recognize the four items contributed by the proxy certificate by their issuer, which is the Subject DN of your GridShib CA-issued EEC. (Note that the pair of BasicAttribute items are labeled (raw). This is because these attributes have not yet been subjected to policy and are therefore only provisionally accepted by GridShib for GT.)
    4. In the second Command Prompt window, stop the container.

Install JWS Core on remote host

  1. Install the binary version of Java WS Core 4.0.5 on UNIX.
    The binary version of Java WS Core is simplest, but the source version works just as well.
    1. Open a Shell Prompt window and extract the GZIP archive to some directory on your hard drive (say, your home directory): 
      $ cd
$ gunzip /tmp/ws-core-4.0.5-bin.tar.gz
$ tar xvf /tmp/ws-core-4.0.5-bin.tar
    2. Change directory to the installation directory, and set the GLOBUS_LOCATION environment variable (which is case sensitive): 
      $ cd ~/ws-core-4.0.5
$ export GLOBUS_LOCATION=`pwd`
$ echo $GLOBUS_LOCATION
    3. For debugging purposes, add the following line to $GLOBUS_LOCATION/container-log4j.properties: 
      log4j.category.org.globus.gridshib.gt=DEBUG
    4. As a crude test, start the container (with transport-level security disabled): 
      > ./bin/globus-start-container -nosec
Starting SOAP server at: http://141.142.251.212:8080/wsrf/services/
With the following services:

[1]: http://141.142.251.212:8080/wsrf/services/AdminService
[2]: http://141.142.251.212:8080/wsrf/services/AuthzCalloutTestService
[3]: http://141.142.251.212:8080/wsrf/services/ContainerRegistryEntryService
[4]: http://141.142.251.212:8080/wsrf/services/ContainerRegistryService
[5]: http://141.142.251.212:8080/wsrf/services/CounterService
[6]: http://141.142.251.212:8080/wsrf/services/ManagementService
[7]: http://141.142.251.212:8080/wsrf/services/NotificationConsumerFactoryService
[8]: http://141.142.251.212:8080/wsrf/services/NotificationConsumerService
[9]: http://141.142.251.212:8080/wsrf/services/NotificationTestService
[10]: http://141.142.251.212:8080/wsrf/services/PersistenceTestSubscriptionManager
[11]: http://141.142.251.212:8080/wsrf/services/SampleAuthzService
[12]: http://141.142.251.212:8080/wsrf/services/SecureCounterService
[13]: http://141.142.251.212:8080/wsrf/services/SecurityTestService
[14]: http://141.142.251.212:8080/wsrf/services/ShutdownService
[15]: http://141.142.251.212:8080/wsrf/services/SubscriptionManagerService
[16]: http://141.142.251.212:8080/wsrf/services/TestAuthzService
[17]: http://141.142.251.212:8080/wsrf/services/TestRPCService
[18]: http://141.142.251.212:8080/wsrf/services/TestService
[19]: http://141.142.251.212:8080/wsrf/services/TestServiceRequest
[20]: http://141.142.251.212:8080/wsrf/services/TestServiceWrongWSDL
[21]: http://141.142.251.212:8080/wsrf/services/Version
[22]: http://141.142.251.212:8080/wsrf/services/WidgetNotificationService
[23]: http://141.142.251.212:8080/wsrf/services/WidgetService
[24]: http://141.142.251.212:8080/wsrf/services/gsi/AuthenticationService
      Press Ctrl-C to abort the container.
  2. Install a trusted certificate
    In what follows, we will use a GridShib CA-issued end-entity certificate (EEC) to authenticate to GT services. We will also issue proxy certificates using a GridShib CA-issued EEC. Thus the container needs to be configured to trust certificates issued by the GridShib CA.
    1. Download the public certificate of the GridShib CA.
    2. Extract the ZIP archive to folder "%USERPROFILE%\.globus\certificates": 
      > dir "%USERPROFILE%\.globus\certificates"
...
02/19/2007  10:15 PM             1,667 bfcd1f28.0
02/19/2007  10:15 PM               239 bfcd1f28.signing_policy
  3. Obtain a user certificate and stop the container normally.
    1. In the previous Command Prompt window, start the container again: 
      > echo %GLOBUS_LOCATION%
> bin\globus-start-container -nosec
Starting SOAP server at: http://141.142.251.212:8080/wsrf/services/
With the following services...
    2. Open another Command Prompt window and try to stop the container: 
      > cd c:\globus\ws-core-4.0.5-bin\ws-core-4.0.5
> set GLOBUS_LOCATION=%CD%
> echo %GLOBUS_LOCATION%
> bin\globus-stop-container
Error: ; nested exception is:
GSSException: Defective credential detected [Caused by:
Proxy file (C:\DOCUME~1\TOMSCA~1\LOCALS~1\Temp\x509up_u_tom scavo) not found.]
    3. Press Ctrl-C to abort the container.
    4. Obtain a short-term X.509 end-entity credential from the online GridShib CA.
    5. In the first Command Prompt window, start the container as before.
    6. In the second Command Prompt window, try to stop the container again: 
      > bin\globus-stop-container
Error: ; nested exception is:
java.net.ConnectException: Connection refused: connect
    7. Finally, stop the container normally, authenticating with your GridShib CA-issued credential via Secure Message: 
      > bin\globus-stop-container -s http://localhost:8080/wsrf/services/ShutdownService -m msg
  4. Start and stop a secure container.
    For the rest of this tutorial, we require a secure container.
    1. In the first Command Prompt window, start the container: 
      > echo %GLOBUS_LOCATION%
> bin\globus-start-container
Starting SOAP server at: https://141.142.250.163:8443/wsrf/services/
With the following services...
    2. In the second Command Prompt window, stop the container: 
      > echo %GLOBUS_LOCATION%
> bin\globus-stop-container
  5. Request the SecureCounterService, authenticating with your EEC via Secure Conversation.
    1. In the first Command Prompt window, start the container: 
      > echo %GLOBUS_LOCATION%
> bin\globus-start-container
Starting SOAP server at: https://141.142.250.163:8443/wsrf/services/
With the following services...
    2. In the second Command Prompt window, request a service: 
      > echo %GLOBUS_LOCATION%
> bin\counter-client -m conv -z none
    -s https://localhost:8443/wsrf/services/SecureCounterService
Got notification with value: 3
Counter has value: 3
Got notification with value: 13
    3. In the second Command Prompt window, stop the container: 
      > bin\globus-stop-container

Install GridShib for GT on remote host

[in progress]

Configure GridShib for GT for attribute push on remote host

Configure attribute acceptance policy

  1. Reconfigure the SecurityContextEchoService on remote host.
    By default, the SecurityContextEchoService is configured to accept all attributes (i.e., no policy is applied). We now expand the authorization chain to include attribute acceptance policy. This policy check is enabled by adding another PIP to the authorization chain
    1. In $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/echo-service-security-descriptor.xml, comment out this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP"/>
      and uncomment this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP"/>
      This enables AttributeAcceptancePIP in the authorization chain.
  2. Request the SecurityContextEchoService, authenticating with a level 1 proxy credential issued on local host.
    Since GridShib for GT does not trust the proxy issuer, any attributes in the proxy certificate will be filtered from the security context.
    1. In the first Shell Prompt window on remote host, start the container.
    2. In the second Command Prompt window on local host, issue a level 1 proxy, set the proxy path, and request the service: 
      > %GRIDSHIB_HOME%\bin\gridshib-saml-issuer --user trscavo
    --authn --x509 --outfile c:\temp\testcredential.pem
    --authnMethod urn:oasis:names:tc:SAML:1.0:am:password
> set X509_USER_PROXY=c:\temp\testcredential.pem
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
      The response will include one SAMLIdentity item issued by the GridShib CA-issued EEC. Although the proxy certificate contains a SAML assertion, the SAML attributes in the proxy were filtered by the AttributeAcceptancePIP since the proxy issuer is not a trusted SAML authority.
    3. In the second Shell Prompt window on remote host, stop the container.
  3. Reconfigure the GridShib SAML Tools on local host.
    Every SAML assertion has an issuer, and the assertion embedded in the proxy certificate by the SAML Tools is no exception. By default, the tool sets the SAML Issuer to the X.509 Issuer, that is, the Subject DN of the issuing credential. We now reconfigure the GridShib SAML Tools so that the SAML Issuer is a fixed URI. This URI is called the entityID of the SAML issuer.
    1. Uncomment the following line in %GRIDSHIB_HOME%\etc\gridshib\tools\gridshib-saml-issuer.properties: 
      IDPEntityID=https://gridshib.example.org/idp
      The URI on the righthand side is the entityID of the SAML issuer.
    2. Obtain the Subject DN of your GridShib CA-issued EEC on local host: 
      > %GLOBUS_LOCATION%\bin\rfc2253dn
      The Subject DN of your EEC is required in the following step.
  4. Configure the AttributeAcceptancePIP on remote host.
    In the current version of GridShib for GT, attribute acceptance policy boils down to a list of trusted SAML authorities. Actually, the PIP consults a file-based mapping of SAML authorities into X.509 authorities. Attributes are accepted from a particular SAML issuer if and only if the issuer's entityID maps to an X.509 Issuer DN. By default, the GridShib CA is a trusted SAML authority. We now add a proxy issuer to the list of trusted SAML authorities.
    1. Add the following line to the trusted SAML authorities file $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/idp-metadata/trusted-authorities-entity-map.txt: 
      https://gridshib.example.org/idp "Subject DN of your EEC"
      Be sure to use the RFC 2253 form of your Subject DN.
  5. Request the SecurityContextEchoService again.
    Since the GridShib SAML Tools is configured by default to issue an assertion with two attributes, you will see an additional four (4) items in the response.
    1. In the first Shell Prompt window on remote host, start the container.
    2. In the second Command Prompt window on local host, set the proxy path and request the service: 
      > echo %X509_USER_PROXY%
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
      You should receive a total of six (6) items in the response: two (2) SAMLIdentity items, one (1) SAMLAuthnContext item, two (2) BasicAttribute items, and one (1) Principal item. Note carefully the issuer of each item. Also note that the BasicAttribute items are no longer labeled (raw) since, by virtue of the AttributeAcceptancePIP, they have been subjected to Attribute Acceptance Policy.
    3. In the second Shell Prompt window on remote host, stop the container.

Configure a blacklist

  1. Reconfigure the SecurityContextEchoService on remote host.
    Specific IP addresses may be blacklisted. Add a blacklist PDP to the authorization chain.
    1. In $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/echo-service-security-descriptor.xml, comment out this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP"/>
      and uncomment this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP
              secctxecho:org.globus.gridshib.SAMLBlacklistPDP"/>
      This enables SAMLBlacklistPDP in the authorization chain.
    2. In $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/server-config.wsdd, replace this line 
      <parameter name="secctxecho-enableBlacklisting" value="false"/>
      with this line 
      <parameter name="secctxecho-enableBlacklisting" value="true"/>
      This enables blacklisting in the SecurityContextEchoService.
  2. Request the SecurityContextEchoService, authenticating with a level 1 proxy credential issued on local host.
    The IP address of the requester is checked against the blacklist and the request is denied if the IP address is on the list. Since IP address 111.111.111.111 is on the blacklist ($GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/blacklist_ip_addresses.txt), the request is denied.
    1. In the first Shell Prompt window on remote host, start the container.
    2. In the second Command Prompt window on local host, issue a level 1 proxy and request the service: 
      > %GRIDSHIB_HOME%\bin\gridshib-saml-issuer --user trscavo
    --authn --x509 --outfile c:\temp\testcredential.pem
    --authnMethod urn:oasis:names:tc:SAML:1.0:am:password --address 111.111.111.111
> echo %X509_USER_PROXY%
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
Error: org.globus.wsrf.impl.security.authorization.exceptions.AuthorizationException:
"/DC=edu/DC=uiuc/DC=ncsa/DC=computer/O=Shibboleth User/OU=entityID/CN=ePPN"
is not authorized to use operation:
{http://wsrf.globus.org/2005/04/secctxecho}echo on this service
      Since the IP address is on the blacklist, the request is denied.
  3. Request the SecurityContextEchoService again.
    In this case, IP address 255.255.255.255 is not on the blacklist, so the request is permitted.
    1. In the second Command Prompt window on local host, issue a different level 1 proxy and request the service: 
      > %GRIDSHIB_HOME%\bin\gridshib-saml-issuer --user trscavo
    --authn --x509 --outfile c:\temp\testcredential.pem
    --authnMethod urn:oasis:names:tc:SAML:1.0:am:password --address 255.255.255.255
> echo %X509_USER_PROXY%
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
      As before, you should receive a total of six (6) items in the response: two (2) SAMLIdentity items, one (1) SAMLAuthnContext item, two (2) BasicAttribute items, and one (1) Principal item. Note that the SAMLAuthnContext item contains the IP address 255.255.255.255 previously embedded in the proxy.
    2. In the second Shell Prompt window on remote host, stop the container.

Configure attribute mapping

  1. Reconfigure the SecurityContextEchoService on remote host.
    SAML attributes may be mapped to local usernames. The mappings are defined in policy files configured in the service descriptor ($GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/server-config.wsdd) on remote host.
    1. In $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/echo-service-security-descriptor.xml, comment out this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP
              secctxecho:org.globus.gridshib.SAMLBlacklistPDP"/>
      and uncomment this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP
              secctxecho:org.globus.gridshib.SAMLBlacklistPDP
              secctxecho:org.globus.gridshib.SAMLMapPIP"/>
      This enables SAMLMapPIP in the authorization chain.
  2. Request the SecurityContextEchoService again.
    If the particular attribute that authorizes access has one or more usernames associated with it, those usernames are added to the security context. (The policy file $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/echo-attr-authz-vo.xml on remote host contains the relevant mappings.)
    1. In the first Shell Prompt window on remote host, start the container.
    2. In the second Command Prompt window on local host, use the level 1 proxy from the previous exercise to request the service: 
      > echo %X509_USER_PROXY%
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
      You should receive a total of seven (7) items in the response: two (2) SAMLIdentity items, one (1) SAMLAuthnContext item, two (2) BasicAttribute items, and two (2) Principal items. The new Principal item is a username mapped to an attribute in the policy file.
    3. In the second Shell Prompt window on remote host, stop the container.

Configure attribute-based authorization policy

  1. Reconfigure the SecurityContextEchoService on remote host.
    We now configure attribute-based authorization policy, the most important policy check of all.
    1. In $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/echo-service-security-descriptor.xml, comment out this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP
              secctxecho:org.globus.gridshib.SAMLBlacklistPDP
              secctxecho:org.globus.gridshib.SAMLMapPIP"/>
      and uncomment this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP
              secctxecho:org.globus.gridshib.SAMLBlacklistPDP
              secctxecho:org.globus.gridshib.SAMLMapPIP
              secctxecho:org.globus.gridshib.SAMLAttributePDP"/>
      This enables SAMLAttributePDP in the authorization chain.
  2. Reconfigure the GridShib SAML Tools on local host.
    1. Create configuration file c:\temp\gridshib-saml-issuer.properties with the following lines: 
      # the IdP entityID
IDPEntityID=https://gridshib.example.org/idp
# a principal name identifier
Format=urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
formatting.template=%PRINCIPAL%
# FriendlyName="eduPersonEntitlement"
Attribute.ROLE.Namespace=urn:mace:shibboleth:1.0:attributeNamespace:uri
Attribute.ROLE.Name=urn:mace:dir:attribute-def:eduPersonEntitlement
Attribute.ROLE.Value=http://www.teragrid.org/names/roles/admin
# an issuing credential (EEC or proxy)
certLocation=file:/C:/temp/testcredential.pem
keyLocation=file:/C:/temp/testcredential.pem
  3. Request the SecurityContextEchoService, authenticating with a level 1 proxy credential issued on local host.
    Using the above configuration file, we will issue a level 1 proxy certificate that does not contain one of the required attributes as specified by policy file $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/echo-attr-authz-vo.xml on remote host. As a result, the request will fail.
    1. In the first Shell Prompt window on remote host, start the container.
    2. In the second Command Prompt window on local host, issue a level 1 proxy and request the service: 
      > copy "%TEMP%\x509up_u_%USERNAME%" c:\temp\testcredential.pem
> %GRIDSHIB_HOME%\bin\gridshib-saml-issuer --user trscavo
    --authn --x509 --outfile c:\temp\testcredential.pem
    --authnMethod urn:oasis:names:tc:SAML:1.0:am:password
    --config file:/c:/temp/gridshib-saml-issuer.properties
> echo %X509_USER_PROXY%
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
Error: org.globus.wsrf.impl.security.authorization.exceptions.AuthorizationException:
"/DC=edu/DC=uiuc/DC=ncsa/DC=computer/O=Shibboleth User/OU=entityID/CN=ePPN"
is not authorized to use operation:
{http://wsrf.globus.org/2005/04/secctxecho}echo on this service
      Since the supplied attribute does not satisfy policy, the request is denied.
  4. Request the SecurityContextEchoService again.
    This time we will present a proxy certificate with at least one attribute that satisfies policy.
    1. In the second Command Prompt window on local host, issue another level 1 proxy and request the service: 
      > %GRIDSHIB_HOME%\bin\gridshib-saml-issuer --user trscavo
    --authn --x509 --outfile c:\temp\testcredential.pem
    --authnMethod urn:oasis:names:tc:SAML:1.0:am:password
> echo %X509_USER_PROXY%
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
      You should receive a total of seven (7) items in the response: two (2) SAMLIdentity items, one (1) SAMLAuthnContext item, two (2) BasicAttribute items, and two (2) Principal items.
    2. In the second Shell Prompt window on remote host, stop the container.

Configure a combined interceptor

  1. Reconfigure the SecurityContextEchoService on remote host.
    A master PDP (also called a combined interceptor) controls other PIPs and PDPs. For example, a PDP called GridShibPDP is functionally equivalent to the authorization chain configured previously. (Actually, GridShibPDP does much more, as we shall see.)
    1. In $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/echo-service-security-descriptor.xml, comment out this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP
              secctxecho:org.globus.gridshib.SAMLBlacklistPDP
              secctxecho:org.globus.gridshib.SAMLMapPIP
              secctxecho:org.globus.gridshib.SAMLAttributePDP"/>
      and uncomment this line 
      <authz value="secctxecho:org.globus.gridshib.GridShibPDP"/>
      This enables the master PDP GridShibPDP.
  2. Request the SecurityContextEchoService, authenticating with a level 1 proxy credential via Secure Message.
    This is a good time to introduce message-level security. The previous request defaulted to transport-level security, that is, the SAML assertions are passed via an ordinary TLS handshake. To pass the SAML assertions at the message level, all that's needed is a simple command-line switch that causes the client to use WS-Security X.509 Token Profile to transmit the certificate chain along with the bound SAML assertions to the container.
    1. In the first Shell Prompt window on remote host, start the container.
    2. In the second Command Prompt window on local host, request the service in two different ways: 
      > %GLOBUS_LOCATION%\bin\gridshibecho -d -z none
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
> %GLOBUS_LOCATION%\bin\gridshibecho -d -z none -m msg
    -s https://localhost:8443/wsrf/services/SecurityContextEchoService
      Both requests should produce a total of seven (7) items in the response: two (2) SAMLIdentity items, one (1) SAMLAuthnContext item, two (2) BasicAttribute items, and two (2) Principal items.
    3. In the second Shell Prompt window on remote host, stop the container.

Configure complex authorization policy

  1. Reconfigure the SecurityContextEchoService on remote host.
    1. In $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/echo-service-security-descriptor.xml, comment out this line 
      <authz value="secctxecho:org.globus.gridshib.GridShibPDP"/>
      and uncomment this line 
      <authz value="secctxecho:org.globus.gridshib.SAMLAssertionPushPIP
              secctxecho:org.globus.gridshib.AttributeAcceptancePIP
              secctxecho:org.globus.gridshib.SAMLBlacklistPDP
              secctxecho1:org.globus.gridshib.SAMLMapPIP
              secctxecho2:org.globus.gridshib.SAMLMapPIP
              secctxecho1:org.globus.gridshib.SAMLAttributePDP
              secctxecho2:org.globus.gridshib.SAMLAttributePDP
              secctxecho3:org.globus.gridshib.SAMLAttributePDP"/>
      This enables SAMLAttributePDP three times in the authorization chain. Each invocation of SAMLAttributePDP is associated with its own policy file. (See $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/server-config.wsdd for the policy file configuration.)
  2. Request the SecurityContextEchoService, authenticating with a level 2 proxy credential issued on local host.
    Previously, an alternate configuration file for the GridShib SAML Tools was created on local host, which we used to issue a level 1 proxy certificate. This time we will use that same configuration file to issue a level 2 proxy certificate.
    1. In the first Shell Prompt window on remote host, start the container.
    2. In the second Command Prompt window on local host, issue a level 2 proxy: 
      > %GRIDSHIB_HOME%\bin\gridshib-saml-issuer --user trscavo
      --authn --x509 --outfile c:\temp\testcredential.pem
      --authnMethod urn:oasis:names:tc:SAML:1.0:am:password
> %GRIDSHIB_HOME%\bin\gridshib-saml-issuer --user trscavo
      --x509 --outfile c:\temp\testcredential.pem
      --config file:/c:/temp/gridshib-saml-issuer.properties
    3. In the second Command Prompt window on local host, request the service as usual (using transport-level security or message-level security, take your pick). You should receive a total of ten (10) items in the response: three (3) SAMLIdentity items (one from each certificate), one (1) SAMLAuthnContext item (from the level 1 proxy), three (3) BasicAttribute items (two from the level 1 proxy and one from the level 2 proxy), and three (3) Principal items (two of which are username mappings).
    4. In the second Shell Prompt window on remote host, stop the container.

Configure GridShib for GT for attribute pull on remote host

The GridShib Project
http://gridshib.globus.org/

Valid XHTML 1.0 Strict