GridShib for Globus Toolkit
Version 0.6.0 Technology Preview 3
June 25, 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.4, GridShib for GT v0.6.0, and GridShib SAML Tools v0.1.4. 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
Install GridShib for GT on local host
Install GridShib SAML Tools on local host
Install JWS Core on remote host
Install GridShib for GT on remote host
Configure GridShib for GT for attribute push on remote host
Configure GridShib for GT for attribute pull on remote host
- TBD

Install JWS Core on local host

Install the binary version of Java WS Core 4.0.4 on Windows.

The binary version of Java WS Core is simplest, but the source version works just as well.

Extract the ZIP archive to any folder on your hard drive (say, c:\globus).
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.4-bin\ws-core-4.0.4
> set GLOBUS_LOCATION=%CD%
> echo %GLOBUS_LOCATION%
```
For debugging purposes, add the following line to %GLOBUS_LOCATION%\container-log4j.properties:
```
log4j.category.org.globus.gridshib.gt=DEBUG
```

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.

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
```

Obtain a user certificate and stop the container normally.

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...

Open another Command Prompt window and try to stop the container:

> cd c:\globus\ws-core-4.0.4-bin\ws-core-4.0.4
> 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.]

Press Ctrl-C to abort the container.
Obtain a short-term X.509 end-entity credential from the online GridShib CA.
In the first Command Prompt window, start the container as before.

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

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
```

Start and stop a secure container.

For the rest of this tutorial, we require a secure container.

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...

In the second Command Prompt window, stop the container:
```
> echo %GLOBUS_LOCATION%
> bin\globus-stop-container
```

Request the SecureCounterService, authenticating with your EEC via Secure Conversation.

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...

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

In the second Command Prompt window, stop the container:
```
> bin\globus-stop-container
```

Install GridShib for GT on local host

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
```
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
```

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.

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...

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:
---------

Security context for identity '/DC=edu/DC=uiuc/DC=ncsa/DC=computer/O=Shibboleth User
                               /OU=urn:mace:inqueue:shib13.openidp.org
                               /CN=trscavo@openidp.org'
SAMLIdentity {
  issuer='CN=GridShib CA,O=Certificate Authority,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: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 {
  username='/DC=edu/DC=uiuc/DC=ncsa/DC=computer/O=Shibboleth User
            /OU=urn:mace:inqueue:shib13.openidp.org
            /CN=trscavo@openidp.org'
}

In the second Command Prompt window, stop the container.

Install GridShib SAML Tools on local host

Install GridShib SAML Tools v0.1.4 on Windows. (See the Installation Notes for detailed information about GridShib SAML Tools.)
We will configure the SAML Tools to sign proxy certificates using your GridShib CA-issued EEC by default.
1. Download the GridShib SAML Tools v0.1.4 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-tools-0_1_4
> set GRIDSHIB_HOME=%CD%
> ant install
```
4. Uncomment the following lines in %GRIDSHIB_HOME%\etc\gridshib\tools\gridshib-saml-issuer.properties:
```
# an EEC issued by the GridShib CA
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.
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
```
  You should receive a total of six (6) items in the 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
  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

Install the binary version of Java WS Core 4.0.4 on UNIX.

The binary version of Java WS Core is simplest, but the source version works just as well.

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.4-bin.tar.gz
$ tar xvf /tmp/ws-core-4.0.4-bin.tar
```
Change directory to the installation directory, and set the GLOBUS_LOCATION environment variable (which is case sensitive):
```
$ cd ~/ws-core-4.0.4
$ export GLOBUS_LOCATION=`pwd`
$ echo $GLOBUS_LOCATION
```
For debugging purposes, add the following line to $GLOBUS_LOCATION/container-log4j.properties:
```
log4j.category.org.globus.gridshib.gt=DEBUG
```

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.

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
```

Obtain a user certificate and stop the container normally.

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...

Open another Command Prompt window and try to stop the container:

> cd c:\globus\ws-core-4.0.4-bin\ws-core-4.0.4
> 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.]

Press Ctrl-C to abort the container.
Obtain a short-term X.509 end-entity credential from the online GridShib CA.
In the first Command Prompt window, start the container as before.

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

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
```

Start and stop a secure container.

For the rest of this tutorial, we require a secure container.

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...

In the second Command Prompt window, stop the container:
```
> echo %GLOBUS_LOCATION%
> bin\globus-stop-container
```

Request the SecureCounterService, authenticating with your EEC via Secure Conversation.

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...

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

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

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.
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 consist of 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.
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. Attributes are accepted from a SAML issuer if and only if the issuer's entityID is on this list. By default, the GridShib CA's entityID is on this list. We now add a proxy issuer to the list of trusted SAML authorities.
1. Obtain the Subject DN of your GridShib CA-issued EEC on local host:
```
> %GLOBUS_LOCATION%\bin\rfc2253dn
```
2. Add the RFC 2253 form of your Subject DN to the trusted SAML authorities file $GLOBUS_LOCATION/etc/gridshib-gt-echo-0_6_0/trusted-saml-authorities.txt on remote host.
Request the SecurityContextEchoService again.
Since the GridShib SAML Tools is configured to issue an assertion with two attributes, you will see a total of four (4) attributes in the logs, the NameIdentifier from the assertion bound to the EEC, plus two attributes and a NameIdentifier bound to the level 1 proxy.
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
```
  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 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

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.
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.
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.
2. In the second Shell Prompt window on remote host, stop the container.

Configure attribute mapping

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.

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.

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. (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

Reconfigure the SecurityContextEchoService on remote host.

We now configure attribute-based authorization policy, the most important policy check of all.

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.

Reconfigure the GridShib SAML Tools on local host.

Create configuration file c:\temp\gridshib-saml-issuer.properties with the following lines:

# 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

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.

In the first Shell Prompt window on remote host, start the container.

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.

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

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.
Request the SecurityContextEchoService, authenticating with a level 1 proxy credential via Secure Message.
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

Reconfigure the SecurityContextEchoService on remote host.

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.)

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/

GridShib for Globus Toolkit Version 0.6.0 Technology Preview 3June 25, 2007

GridShib for Globus Toolkit
Version 0.6.0 Technology Preview 3
June 25, 2007