Project site: http://www.perfsonar.net/jra1-wiki/index.php

Summary of perfSONAR Use Case Characteristics:

Web-initiated, client, and server-based access to distributed/dynamic monitoring resources and tools using standard Web Service protocols.
Resources may be in the same or different domain as the requester.
Local authentication, remote authorization.
Resources/services are highly dynamic, can be transitory, and may run in untrusted environments.
Authorization decision-making are delegated to an Authorization Service (AS) that is trusted to return access policy decisions to resources based on credentials associated with requests.

Security and Privacy Requirements

Information about end users should not be exposed to resources or managed on a per-resource basis.
Both bearer and key-based security tokens should be supported.

An example sequence:

Browser authenticates to perfSONAR web-based client.
User makes request to web-based client to access perfSONAR resource/tool.
perfSONAR client requests new security token from user's !IdP
perfSONAR client invokes resource, attaching security token.
perfSONAR resource verifies message and passes token to AS for evaluation.
AS evaluates token and returns authorization decision.
Resource responds to client.

Browser Authentication to perfSONAR Client

In step 1, initial authentication to the perfSONAR client takes place. The client runs behind a web server and provides a web-based interface for easy access/deployment. This step can be achieved with any web browser authentication profile resulting in a SAML 2.0 assertion presented to the SP, such as the SAML 2.0 Browser SSO or EnhancedClient profiles.

The additional requirement is for the user to delegate permission to the SP to make additional token requests on his/her behalf. This should be a fairly innocuous policy to enable, as it doesn't in and of itself provide the SP with the ability to obtain any particular access. To reflect this capability, the IdP is responsible for embedding additional SubjectConfirmation and Audience elements authorizing the SP to present the assertion back to the IdP in step 3.

Example

The example shows an "exchangeable" token issued to https://perfSONAR-client.example.edu/entity by https://idp.example.edu/entity , valid for an hour.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0"
		  ID="_682C46C8-198A-436C-9E0F-DBBC155DE413" IssueInstant="2006-01-27T02:28:36Z">
	 <saml:Issuer>https://idp.example.edu/entity</saml:Issuer>
	 <ds:Signature>...</ds:Signature>
	 <saml:Subject>

		  <!-- the identifier is scoped between the !IdP and the SP -->
		  <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
			 E8042FB4-4D5B-48C3-8E14-8EDD852790DD
		  </saml:NameID>

		  <!-- the bearer authorization is for web SSO by the browser to the SP -->
		  <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
				<saml:SubjectConfirmationData Address="192.168.1.1"
					 Recipient="https://perfSONAR-client.example.edu/Shibboleth.sso/SAML2/ACS"
					 NotBefore="2006-01-27T02:28:36Z" NotOnOrAfter="2006-01-27T02:33:36Z"/>
		  </saml:SubjectConfirmation>

		  <!-- the HoK authorization is for re-presentation to the !IdP by the SP -->
		  <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
				<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
				  https://perfSONAR-client.example.edu/entity
				</saml:NameID>
				<saml:SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
					 <ds:KeyInfo>...<ds:KeyInfo>
				</saml:SubjectConfirmationData>
		  </saml:SubjectConfirmation>

	 </saml:Subject>

	 <!-- the conditions apply to all uses, and the assertion is scoped to both the !IdP and SP -->
	 <saml:Conditions NotBefore="2006-01-27T02:28:36Z" NotOnOrAfter="2006-01-27T03:28:36Z">
		  <saml:AudienceRestriction>
				<saml:Audience>https://perfSONAR-client.example.edu/entity</saml:Audience>
				<saml:Audience>https://idp.example.edu/entity</saml:Audience>
		  </saml:AudienceRestriction>
	 </saml:Conditions>

	 <saml:AuthnStatement AuthnInstant="2006-01-27T02:10:00Z"
				SessionIndex="_682C46C8-198A-436C-9E0F-DBBC155DE413">
		  <saml:SubjectLocality Address="192.168.1.1"/>
		  <saml:AuthnContext>
				<saml:AuthnContextClassRef>
				  urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
				<saml:AuthnContextClassRef>
				<saml:AuthnContextDeclRef>
				  https://idp.example.edu/SAML2/AC/Kerberos.xml
				<saml:AuthnContextDeclRef>
		  </saml:AuthnContext>
	 </saml:AuthnStatement>

	 <saml:AttributeStatement>
	 ...
	 </saml:AttributeStatement>
</saml:Assertion>

User Requests Access to perfSONAR Resource/Tool

This step is out of scope, but it's mentioned as a placeholder for whether or not discovery of remote resources is in-scope or not. Various approaches might be used for service discovery, including the LibertyWSFDiscovery service, which could be used to merge service lookup with the following step for getting the necessary credentials.

perfSONAR Client Requests New Security Token

To request the credentials it needs for the remote service, the perfSONAR client exchanges the original assertion issued to it in step 1 for a new assertion using the SAML Token Service profile defined in the LibertyWSFAuthentication spec. This takes the form of a SOAP request to the IdP's SSO Service endpoint containing a SAML AuthnRequest message. The original assertion is attached to the signed request using the LibertyWSFSOAPBinding.

The AuthnRequest identifies the remote resource for which credentials are required. This is most likely represented by the AS governing those resources, rather than the actual resource. It can optionally specify a variety of additional policy information, but in most cases can be left fairly simple. The !IdP should usually have enough pre-established policy or can rely on a number of mechanisms (out of scope) to determine the security policies.

Example

The example shows the token issued in step 1 used to secure a request for a new token issued by https://idp.example.edu/entity for securing calls to https://perfSONAR-AS.remote.edu/entity

The SOAP exchange with the IdP takes place over a mutually authenticated TLS connection in lieu of a message signature.

First, the SOAP request:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

	 <S:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"
		  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
		  xmlns:sbf="urn:liberty:sb"
		  xmlns:sb="urn:liberty:sb:2005-11">

		  <sbf:Framework version="2.0"/>
		  <sb:Sender wsu:Id="sender" providerID="https://perfSONAR-client.example.edu/entity"/>

		  <wsa:MessageID wsu:Id="mid">uuid:efefefef-aaaa-ffff-cccc-eeeeffffbbbb</wsa:MessageID>
		  <wsa:To wsu:Id="to">https://idp.example.edu/entity</wsa:To>
		  <wsa:Action wsu:Id="action">urn:liberty:ssos:2005-11:AuthnRequest</wsa:Action>
		  <wsa:ReplyTo wsu:Id="replyto">
				<wsa:Address>http://www.w3.org/2005/08/addressing/role/anonymous</wsa:Address>
		  </wsa:ReplyTo>

		  <wsse:Security S:mustUnderstand="1"
				xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

				<wsu:Timestamp wsu:Id="ts">
					 <wsu:Created>2006-01-27T02:48:00Z</wsu:Created>
				</wsu:Timestamp>

				<!-- this is the assertion from step 1 -->
				<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0"
					 ID="_682C46C8-198A-436C-9E0F-DBBC155DE413" IssueInstant="2006-01-27T02:28:36Z">
					 ....
				</saml:Assertion>

				<!-- no message signature present, TLS used instead -->
		  </wsse:Security>
	 </S:Header>

	 <S:Body wsu:Id="MsgBody">
		  <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
					 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0"
					 ID="_E47945FB-C3F3-4f2C-991C-A2E2B2C59F3C" IssueInstant="2006-01-27T02:48:00Z"
					 ProtocolBinding="http://www.w3.org/2005/08/addressing/role/anonymous">

				<!--
				saml:Issuer omitted and ProtocolBinding set above in accordance with Liberty SSOS spec;
				lack of saml:Subject or samlp:NameIDPolicy signal the IdP to default the assertion content
				-->

				<!-- the conditions identify the back-end services we're asking to access -->
				<saml:Conditions>
					 <saml:AudienceRestriction>
						  <saml:Audience>https://perfSONAR-AS.remote.edu/entity</saml:Audience>
					 </saml:AudienceRestriction>
				</saml:Conditions>

		  </samlp:AuthnRequest>
	 </S:Body>
</S:Envelope>

Then, the SOAP response:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

	 <S:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"
		  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
		  xmlns:sbf="urn:liberty:sb"
		  xmlns:sb="urn:liberty:sb:2005-11">

		  <sbf:Framework version="2.0"/>
		  <sb:Sender providerID="https://idp.example.edu/entity"/>

		  <wsa:MessageID>uuid:071BCD36-FE77-470D-9AA9-9B5628D08727</wsa:MessageID>
		  <wsa:RelatesTo>uuid:efefefef-aaaa-ffff-cccc-eeeeffffbbbb</wsa:RelatesTo>
		  <wsa:To>https://perfSONAR-client.example.edu/entity</wsa:To>
		  <wsa:Action>urn:liberty:ssos:2005-11:Response</wsa:Action>

		  <wsse:Security>
				<wsu:Timestamp>
					 <wsu:Created>2006-01-27T02:49:00Z</wsu:Created>
				</wsu:Timestamp>
		  </wsse:Security>
	 </S:Header>

	 <S:Body>
		  <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
					 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
					 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
					 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
					 Version="2.0" ID="_01CA983A-A889-45AD-BB5C-08DEA1041EE0"
					 IssueInstant="2006-01-27T02:49:00Z">

				<!-- saml:Issuer omitted in accordance with Liberty SSOS spec -->
				
				<samlp:Status>
					 <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
				</samlp:Status>

				<saml:Assertion Version="2.0" ID="_B6EE95E8-54A1-48EB-9A24-68868419FCCB"
						  IssueInstant="2006-01-27T02:49:00Z">
					 <saml:Issuer>https://idp.example.edu/entity</saml:Issuer>
					 <ds:Signature>...</ds:Signature>
					 <saml:Subject>

						  <!-- the identifier is scoped between the !IdP and the back-end SP -->
						  <saml:EncryptedID>
								<xenc:EncryptedData>...</xenc:EncryptedData>
						  </saml:EncryptedID>

						  <!-- the HoK authorization is for presentation by the SP to the back-end SP -->
						  <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
								<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
								  https://perfSONAR-client.example.edu/entity
								</saml:NameID>
								<saml:SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
									 <ds:KeyInfo>...<ds:KeyInfo>
								</saml:SubjectConfirmationData>
						  </saml:SubjectConfirmation>

					 </saml:Subject>

					 <saml:Conditions NotBefore="2006-01-27T02:49:00Z" NotOnOrAfter="2006-01-27T03:49:00Z">
						  <saml:AudienceRestriction>
								<saml:Audience>https://perfSONAR-AS.remote.edu/entity</saml:Audience>
						  </saml:AudienceRestriction>
					 </saml:Conditions>

					 <saml:AuthnStatement>
						  <!-- roughly same information as original assertion -->
						  <!-- note that a high granularity AuthnInstant is a correlation problem -->
					 </saml:AuthnStatement>

					 <saml:AttributeStatement>
						  <!-- encrypyed attributes tailored to remote AS -->
					 </saml:AttributeStatement>
				</saml:Assertion>

		  </samlp:Response>
	 </S:Body>
</S:Envelope>

perfSONAR Client Invokes Resource, Attaching Token.

For a SOAP-based perfSONAR service, the LibertyWSFSOAPBinding can be applied directly, in the same fashion as in step 3. We can use a variety of LibertyWSFSecurity mechanisms in this step, with or without message signing.

Example

The example shows an application request message issued by https://perfSONAR-client.example.edu/entity to https://perfSONAR-AS.remote.edu/entity

The SOAP exchange again takes place over a mutually authenticated TLS connection in lieu of a message signature.

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

	 <S:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"
		  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
		  xmlns:sbf="urn:liberty:sb"
		  xmlns:sb="urn:liberty:sb:2005-11">

		  <sbf:Framework version="2.0"/>
		  <sb:Sender wsu:Id="sender" providerID="https://perfSONAR-client.example.edu/entity"/>

		  <wsa:MessageID wsu:Id="mid">uuid:01493C23-A6F2-47A4-98BF-D9C54189ADC2</wsa:MessageID>
		  <wsa:To wsu:Id="to">https://perfSONAR-AS.remote.edu/entity</wsa:To>
		  <wsa:Action wsu:Id="action">...</wsa:Action>
		  <wsa:ReplyTo wsu:Id="replyto">
				<wsa:Address>http://www.w3.org/2005/08/addressing/role/anonymous</wsa:Address>
		  </wsa:ReplyTo>

		  <wsse:Security S:mustUnderstand="1"
				xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

				<wsu:Timestamp wsu:Id="ts">
					 <wsu:Created>2006-01-27T03:00:00Z</wsu:Created>
				</wsu:Timestamp>

				<!-- this is an assertion from step 3 -->
				<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0"
					 ID="_B6EE95E8-54A1-48EB-9A24-68868419FCCB" IssueInstant="2006-01-27T02:49:00Z">
					 ....
				</saml:Assertion>

				<!-- no message signature present, TLS used instead -->
		  </wsse:Security>
	 </S:Header>

	 <S:Body wsu:Id="MsgBody">
	 ...application specific content...
	 </S:Body>
</S:Envelope>

perfSONAR Resource Verifies Message, Passes Token to AS

The incoming SOAP message from the client is verified for the basic security requirements imposed by the resource/tool, and to ensure the client's obligations are met based on the requirements of the security token. Note that this is separate from actually evaluating the token for the purposes of authorization.

For example, a key-confirmed assertion has to be accompanied by a signature or possibly a TLS client certificate with a corresponding key. Alternatively a bearer token might require nothing.

Once the basic message security requirements and token obligations are met, the resource can defer the token to the so-called AS for decryption and a policy decision. This step could be accomplished with XACML or perhaps with a SAML <AuthzDecisionQuery>, with the assertion included as evidence for the decision.

Example

TODO

AS Evaluates Token and Returns Decision

The attributes (if any) in the token, along with the subject, were encrypted by the !IdP for consumption by the AS. The resource can't actually see user data, but the AS can recover the information and either use it directly, or initiate additional requests for further data about the subject using SAML queries, Liberty services, LDAP queries, etc. Note that this could be facilitated by including LibertySOAPBinding endpoint references inside the security token for use by the AS.

Once enough information is known to make a decision, the AS can respond to the resource and return a decision about access.

Example

TODO

Resource Responds to Client.

Finally, the resource can return a SOAP response to the client either signaling failure, returning data, instructions for where to access a data stream, etc.

Example

TODO

%COMMENT%