-
Notifications
You must be signed in to change notification settings - Fork 18
Security|InterfaceControlDocument
| Wiki Reorganisation |
|---|
| This page has been classified for reorganisation. It has been given the category REVISE. |
| This page contains useful content but needs revision. It may contain out of date or inaccurate content. |
This document outlines the protocol and interfaces used across the ESG Federation (ESGF) for secure access of the ESGF data. This document provides details needed for setting up security services to participate in ESGF, and security specifications for developing any clients for these services. The following diagram depicts the security related logical components of the ESG Federation.
The Gateway performs the functions of Identity Provider, attribute management and administrator and controller of authorisation policy. Users can register and apply for access to data via the User Registration and Membership interfaces. These are HTTP based. The Data Node serves data via the various applications shown in the second column in the Data Node component. These are protected by various filters shown in the first column. HTTP based applications accept OpenID or SSL client based authentication. Authorisation filters delegate access control decisions to the Authorisation Service hosted at an associated Gateway.
To access secure ESG resources, users and clients are required to authenticate using either OpenID or SSL with PKI credentials. Each user is uniquely identified within the ESGF by his/her OpenID, which is issued by the user's Identity Provider.
- OpenID version 2.0 is used for authentication, and optional attribute propagation.
- All Identity Providers require SSL and listen only on HTTPS endpoints.
- The channel between the Identity Provider and the Relying Party is over SSL, and is mutually authenticated. [PJK3]
- OpenID identifiers issued are Yadis IDs, and XRI identifiers are not allowed.
- Relying parties enforce Identity Provider white list once the OpenID protocol discovery establishes the OpenID provider to contact.
- An individual organization's deployed Relying Party(s) may accept IdPs from outside the federation if they wish but they do so at their own risk. They may enable users with such OpenIDs to access resources within their organization but such OpenIDs may not be allocated ESG federation wide attributes. Only users with OpenIDs from one of the trusted IdPs may be allocated ESG federation attributes.
-
Every ESG user must have an X.509 certificate from a Certificate Authority trusted by the ESG federation.
-
User X.509 certificates contain the user's OpenID as the certificate Distinguished Name CN field e.g. /O=ESG Org/OU=Climate Modeling Group/CN= http://myname.openid.esgorg.ac.uk .
-
ESG federation resources can be accessed only with certificates from CA trusted by the ESG Federation.
-
Issued PKI credentials are stored on the local file system at $HOME/.esg/credentials.pem.
-
Downloaded trust root data from the MyProxy server is stored on the local file system in the $HOME/.esg/certificates/ directory.
-
It is recommended that the PKI credentials issued to the users be short-term credentials, so as to reduce revocation burden. But none of the protocols depend on the lifetime of the credential.
HTTP based services such as TDS (THREDDS Data Server) support PKI based authentication by means of HTTP redirects and SSL:
- Request from client over HTTP
- Server returns a HTTP 30x response requesting the client to redirect to a HTTPS endpoint
- Client redirects to HTTPS authentication endpoint submitting a client certificate in the SSL handshake.
- SSL endpoint authenticates user and if this succeeds, returns the user a HTTP 30x response to redirect back to the URI of the service originally invoked. If it fails, the endpoint returns a HTTP 401 response to the client.
- The server receives the request from the client following authentication. This time it includes information to set an authenticated session context.
- The server may execute further steps to carry out authorization of the client.
- Data services may set a query argument in the URL specifying to the Authentication service the URL to return to following authentication. This is currently specific to a given implementation and is not defined by this ICD.
Authentication services should issue assertions that are limited by the credential presented to the authentication service. The lifetime of the authentication assertion should be limited by the lifetime of the credential presented to it.
Specifically, for implementations that uses OpenID for authentication, the cookie should be a session limited cookie. In addition, if a X.509 Certificate based authentication is used for primary authentication, and a cookie is used to persist state, then the lifetime of the cookie should be limited to lifetime of the credential. In some implementation, this is done by use of SAML Authentication assertions in the cookie with the said lifetime set. If no such credential used for primary authentication, the cookie lifetime cannot exceed 12 hours.
Trusted parties within the ESGF exchange two kinds of user attributes:
- A limited amount of user personal information, specifically the user first and last name and his/her email address. These attributes can be part of the authentication protocol, or could be pulled explicitly from an attribute service. (Site Attributes)
- Access control attributes used to restrict access to data and computational resources. It is expected that these attributes will be pulled from an attribute service, and should not be sent via OpenID authentication. Applications using PKI based authentication such as GridFTP and the Publisher client, may consume these attributes via the SAML extension added to user certificates. (VO Attributes).
The minimal attribute set agreed across the federation include:
- First name of the user as type String.
- Last name of the user as type String.
- Email address of the user as type String.
Only the site attributes should be distributed via the authentication mechanism, and no other VO attributes should be shared.
In addition to the attributes mentioned above, some attributes are used for access control in ESGF. The federation has agreed to attribute namespaces and owners, and are listed in the following table:
| Number | Namespace | Owner |
|---|---|---|
| 1 | urn:esgf:ncar | NCAR |
| 2 | urn:esgf:pcmdi | PCMDI |
| 3 | urn:esgf:nasa:jpl | JPL |
| 4 | urn:esgf:badc | BADC |
| 5 | urn:esgf:dkrz | DKRZ |
| 6 | urn:esgf:ornl | ORNL |
| 7 | urn:esgf:nersc | NERSC |
The following attribute is used by many of the federation sites:
- :grouprole: The name of an access control group the user belongs to and the specific role the user has been assigned within the group
Examples of the above attributes, with values, and ownership:
| Number | Attribute Name | Attribute Value | Owner |
|---|---|---|---|
| 1 | urn:esgf:pcmdi:grouprole | CMIP5:admin | PCMDI |
| 2 | urn:esgf:ncar:grouprole | testgroup:admin | NCAR |
Note that each user may be assigned more than one role within the same access control group, resulting in multiple (Group, Role) attribute combinations.
Across the federation the following attribute values have been agreed for particular access control permissions:
- AR5 data access: The following values are assigned to group/role attribute to any user who is granted access to the AR5 data. The assigning of this attribute is managed by PCMDI.
1. Group/Role Attribute:
- Attribute Name: urn:esgf:pcmdi:grouprole
- Attribute Type: String
- Attribute Values: Group = "CMIP5 Research" or "CMIP5 Commercial", Role = "default"
- Data Replication: The attribute group us set to value "BDM" for any replication of the data. The source of the data controls the attribute and its issuance, and the attribute can be used by any of those namespaces. For example, if the source of the data is PCMDI, then the attribute will be urn:esgf:pcmdi:grouprole, and set to value BDM. Similarly the role attribute should be assigned by the source to "admin".
The Attribute Service assigns attributes to the users for data access, and also provides query interface for accessing this information remotely. Attribute services can be hosted in two ways: An Attribute Service may be deployed in association with an Identity Provider. Any SoA (Source of Authority), which has responsibilities for a specific data set or a group of data sets, could host an attribute service. Such attribute services are associated with the resources they protect, and may have users registered with them from a number of different Identity Providers from within the ESG federation. The attribute is agreed across the federation, and any access to these resources is protected by policy that the user must have the agreed attribute value.
ESGF Attribute Services are required to use SAML (the Security Assertion Mark- up Language with the SAML SOAP (Simple Object Access Protocol) binding for message interchange between itself and a client:
It has been agreed that SAML v 2.0 will be used for representation and the SAML protocol with SOAP bindings for querying and retrieving attributes from remote attribute services. The Attribute Service interface uses the standard SAML Assertion Query/Request Profile. It has a single operation:
samlp:Request with saml: AttributeQuery as input samlp:Response with saml:Assertion with saml: AttributeStatement as output
All interactions with the service should be over SSL with mutual authentication.
Across the federation, user attributes need to be propagated for access control to resources. Other than pulling down attributes from the attribute services, user attribute can be pushed as part of the OpenID and PKI authentication mechanism.
ESG federation agreed site attributes are pushed with any OpenID login, using OpenID Attribute Exchange Extension. The attributes are encoded as strings. An example is provided in Section 10.1.1. The minimal set of attributes sent as part of the OpenID login include the first name, last name and email addresses, and are encoded using the names urn:esg:first:name, urn:esg:last:name and urn:esg:email:address. Some Identity Providers may be unable to support an AX interface for their OpenID Provider and so cannot push attributes using this mechanism. In this case, they may host an Attribute Service, which can support a SAML Assertion Query/Request based on a user's OpenID to retrieve the mandatory ESG firstname, lastname and e-mail address attributes.
VO attributes can be embedded as part of the user's X.509 Certificate. It is required that the VO attribute "group" should be embedded in the user's X.509 Certificate. The attribute is embedded as SAML v2.0 Assertion with AttributeStatement , as part of a non-critical certificate extension, with OID "1.2.3.4.4.3.2.1.7.8". The value of the extension is UTF-8 encoded saml:Assertion.
OpenID version 2.0 uses the Yadis4 protocol to enable the discovery of an OpenID Provider service endpoint from a given OpenID URL. ESGF exploits this capability by enabling the discovery of other additional identity services associated with the given OpenID URL. Retrieval of the OpenID URL yields an XRD document which facilitates an number of entries for individual service endpoints. Services are assigned a unique identifier and a value to indicate their priority of use with respect to the other entries. ESGF adds these two entries:
- Attribute Service endpoint
- MyProxy Service endpoint
This is illustrated by an example:
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<Type>http://openid.net/signon/1.0</Type>
<URI>https://openid.provider.somewhere.ac.uk</URI>
<LocalID>https://somewhere.ac.uk/openid/PJKershaw</LocalID>
</Service>
</XRD>
<XRD>
<Service priority="10">
<Type>urn:esg:security:myproxy-service</Type>
<URI>socket://myproxy-server.somewhere.ac.uk:7512</URI>
<LocalID>https://somewhere.ac.uk/openid/PJKershaw</LocalID>
</Service>
</XRD>
<XRD>
<Service priority="20">
<Type>urn:esg:security:attribute-service</Type>
<URI>https://attributeservice.somewhere.ac.uk</URI>
<LocalID>https://somewhere.ac.uk/openid/PJKershaw</LocalID>
</Service>
</XRD>
</xrds:XRDS>
-
The entries must each have a special ID attribute. The OpenID service type is defined in the OpenID specification. ESGF XRD documents should follow this. For the MyProxy service the ID urn:esg:security:myproxy-service is used. For the Attribute Service: urn:esg:security:attribute-service.
-
They must be assigned a lower priority to than the OpenID Provider endpoint entry. ESGF will use "0" to denote the OpenID Provider service priority, "10" for the MyProxy server and "20" for the Attribute Service.
-
Due to a bug in the current implementation of OpenID4Java and Python implementations, the OpenID Provider entry must be the last entry in the XRD document.
These entries are added, to facilitate two new use cases:
- Data Node Manager Notification - get user e-mail address by retrieving Yadis document, getting Attribute Service endpoint and querying this service.
- Gateway MyProxyLogon initialization - initialize this application's start up settings with the user's MyProxy server address obtained by retrieving the Yadis document.
The authorization service provides a remote interface for ESGF resources to obtain a decision on access requests to the resource.
Authorization services across the ESGF should use SAML v2.0 with SOAP bindings for query and response of authorization decisions. The services should listen on a SSL endpoint, and accept requests only from clients that present certificates from a trusted ESGF CA.
The service has a single operation with following specification:
SAMLRequest contains a AuthzDecisionQuery as input SAMLResponse contains an Assertion with AuthzDecisionStatement as output.
SAMLRequest should be parsed, and for each action specified should be evaluated and a AuthzDecisionStatement with only permitted actions and decisions set to Permit returned to the caller. The service may also return a decision of Denied when access to the resource is denied, or Undetermined when an authorization decision cannot be established (for example, if the resource is unknown).
SOAP/SAML Request
The AuthzDecisionQuery request must be keyed on the user's OpenID (which uniquely identifies the user within the federation), a particular resource, and a single specific action. The Format of the OpenID has been agreed to "urn:esg:openid".
The resource is represented by its access URL, and the default SAML action namespace (urn:oasis:names:tc:SAML:1.0:action:rwedc-negation) is used. However, only the action values "Read", and "Write" are expected to be employed. This is the standard namespace to use for federated access but it does not preclude organizations from using other namespaces for access to their local resources.
SOAP/SAML Response
The AuthzDecisionStatement response references the AuthzDecisionQuery it's in response to, along with the decision for the query request. One AuthzDecisionStatement is issued for each AuthzDecisionQuery the Authorization Service receives.
A SoA may host a HTTP based user registration interface to enable users to register for attributes under the authority of the SoA. This process may be asynchronous, for example with an e-mail based notification to let a user know if they qualify for the requested attribute(s). Once the user has registered, a record is held by the SoA such that any trusted agent within the federation may query the SoA's Attribute Service to assert whether the user is registered for the given attribute(s).
The Data Node Manager requires users' e-mail address in order to perform e-mail based notification. It resolves e-mail address from a user's OpenID by querying the user's OpenID URL to obtain their Gateway's Attribute Service endpoint and then querying the Attribute Service to obtain the e-mail address. The Data Node Manager must authenticate the OpenID URL based on the OpenID Provider whitelist and the Attribute Service must be configured to allow queries only from authorised Data Node Manager's from within the federation.
The publisher client uses SSL client based authentication for its Hessian interface to the Gateway for publishing. Attributes for access must be embedded in the certificate within a SAML attribute assertion. Publisher attributes are issued and under the authority of the individual Gateway being published to.
Individual Gateways have the responsibility to administer the Bulk Data Movement Administrator attribute, the attribute which enable users to replicate datasets under their authority. This has the XML type groupRole (see 10.2) with group value set to BDM and role value: admin. The name of the attribute will be of the form urn:esg::grouprole where is the individual unique organization name.
Security services within the federation are secured with SSL based mutual authentication. Certificates from peers must verify against a limited set of accepted CAs and certificate Distinguished Names are limited by whitelists. The whitelisting and CA certificate lists are managed by a single central provisioning service. Individual services within the federation must have their respective certificate DNs and issuing CA certificates registered with this provisioning service. They must be configured to regularly query the provisioning service to update trust store and certificate whitelist settings.
The provisioning service shall serve data over a HTTPS connection. Clients must authenticate the identity of the provisioning service. The provisioning service's SSL settings must be communicated to organisations in the federation so they can correctly configure their clients to authenticate.
The following identifiers are used for first name, last name and e-mail address respectively,
http://openid.net/schema/namePerson/first
http://openid.net/schema/namePerson/last
http://openid.net/schema/contact/internet/email
https://ceda.ac.uk/OpenID/Provider/server?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.claimed_id=https%3A%2F%2Fceda.ac.uk%2Fopenid%2FLuca.Cinquini&openid.identity=https%3A%2F%2Fceda.ac.uk%2Fopenid%2FLuca.Cinquini&openid.return_to=https%3A%2F%2Flocalhost%3A8443%2FESG-CET%2Fj_spring_openid_security_check&openid.realm=https%3A%2F%2Flocalhost%3A8443%2FESG-CET%2Fj_spring_openid_security_check&openid.assoc_handle=%7BHMAC-SHA256%7D%7B4b99774b%7D%7Bg4bPAw%3D%3D%7D&openid.mode=checkid_setup&openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ext1.mode=fetch_request&openid.ext1.type.firstname=http%3A%2F%2Fopenid.net%2Fschema%2FnamePerson%2Ffirst&openid.ext1.type.middlename=http%3A%2F%2Fopenid.net%2Fschema%2FnamePerson%2Fmiddle&openid.ext1.type.lastname=http%3A%2F%2Fopenid.net%2Fschema%2FnamePerson%2Flast&openid.ext1.type.email=http%3A%2F%2Fopenid.net%2Fschema%2Fcontact%2Finternet%2Femail&openid.ext1.required=firstname%2Clastname%2Cemail&openid.ext1.type.username=http%3A%2F%2Fopenid.net%2Fschema%2FnamePerson%2Ffriendly&openid.ext1.type.organization=http%3A%2F%2Fopenid.net%2Fschema%2Fcompany%2Fname&openid.ext1.type.city=http%3A%2F%2Fopenid.net%2Fschema%2Fcontact%2Fcity%2Fhome&openid.ext1.type.state=http%3A%2F%2Fopenid.net%2Fschema%2Fcontact%2Fstate%2Fhome&openid.ext1.type.country=http%3A%2F%2Fopenid.net%2Fschema%2Fcontact%2Fcountry%2Fhome&openid.ext1.type.uuid=http%3A%2F%2Fopenid.net%2Fschema%2Fperson%2Fguid&openid.ext1.type.gateway=http%3A%2F%2Fwww.earthsystemgrid.org%2Fgateway&openid.ext1.if_available=middlename%2Cusername%2Corganization%2Ccity%2Cstate%2Ccountry%2Cuuid%2Cgateway
Name identifiers are OpenID URLs set with the NameID. A custom attribute type is used, groupRole
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.earthsystemgrid.org/"
xmlns="http://www.earthsystemgrid.org/"
elementFormDefault="qualified">
<xs:element name="groupRole">
<xs:complexType>
<xs:attribute name="group" type="xs:string" use="required"/>
<xs:attribute name="role" type="xs:string" default="default" use="optional"/>
</xs:complexType>
</xs:element>
</xs:schema>
The custom SAML attribute type defines group and role parameters. Role may default to the "default" value.
<?xml version="1.0" encoding="UTF-8"?>
<soap11:Envelope
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
<soap11:Body>
<samlp:AttributeQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="9b0061a4-7102-4e21-8748-5a993b95548e" IssueInstant="2009-08-05T19:20:09.089Z" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">ESG-PCMDI</saml:Issuer>
<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:NameID Format="urn:esg:openid">https://esg.ucar.edu/myopenid/testUser</saml:NameID
</saml:Subject>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="FirstName" Name="urn:esg:first:name" NameFormat="http://www.w3.org/2001/XMLSchema#string"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="LastName" Name="urn:esg:last:name" NameFormat="http://www.w3.org/2001/XMLSchema#string"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="EmailAddress" Name="urn:esg:email:address" NameFormat="http://www.w3.org/2001/XMLSchema#string"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="GroupRole" Name="urn:esg:pcmdi:grouprole" NameFormat="groupRole"/>
</samlp:AttributeQuery>
</soap11:Body>
</soap11:Envelope>
<?xml version="1.0" encoding="UTF-8"?><soap11:Envelope xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
<soap11:Body>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="51907a4b-e1f8-4a46-88b2-7dd495a59b0e" InResponseTo="9b0061a4-7102-4e21-8748-5a993b95548e" IssueInstant="2010-03-29T19:43:49.281Z" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=esg-cet.ucar.edu, OU=Services, DC=doegrids, DC=org</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="bbbe7ee2-2301-41ac-b785-1dba252c6514" IssueInstant="2010-03-29T19:43:49.308Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectName">CN=esg-cet.ucar.edu, OU=Services, DC=doegrids, DC=org</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:esg:openid">https://esg.ucar.edu/myopenid/testUser</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2010-03-29T19:43:49.308Z" NotOnOrAfter="2010-03-30T19:43:49.308Z"/>
<saml:AttributeStatement>
<saml:Attribute FriendlyName="FirstName" Name="urn:esg:first:name" NameFormat="http://www.w3.org/2001/XMLSchema#string">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Test</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="LastName" Name="urn:esg:last:name" NameFormat="http://www.w3.org/2001/XMLSchema#string">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">User</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="EmailAddress" Name="urn:esg:email:address" NameFormat="http://www.w3.org/2001/XMLSchema#string">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">luca@ucar.edu</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="GroupRole" Name="urn:esg:ncar:grouprole" NameFormat="groupRole">
<saml:AttributeValue>
<esg:groupRole xmlns:esg="http://www.earthsystemgrid.org" group="CCSM" role="default"/>
</saml:AttributeValue>
<saml:AttributeValue>
<esg:groupRole xmlns:esg="http://www.earthsystemgrid.org" group="Dynamical Core" role="default"/>
</saml:AttributeValue>
<saml:AttributeValue>
<esg:groupRole xmlns:esg="http://www.earthsystemgrid.org" group="NARCCAP" role="default"/>
</saml:AttributeValue>
<saml:AttributeValue>
<esg:groupRole xmlns:esg="http://www.earthsystemgrid.org" group="NCL" role="default"/>
</saml:AttributeValue>
<saml:AttributeValue>
<esg:groupRole xmlns:esg="http://www.earthsystemgrid.org" group="PyNGL" role="default"/>
</saml:AttributeValue>
<saml:AttributeValue>
<esg:groupRole xmlns:esg="http://www.earthsystemgrid.org" group="PyNIO" role="default"/>
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
</soap11:Body>
</soap11:Envelope>
<?xml version="1.0" encoding="UTF-8"?>
<soap11:Envelope xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
<soap11:Body>
<samlp:AuthzDecisionQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="7658c723-7aef-478c-badf-c6cee670761f" IssueInstant="2010-01-26T18:18:10.927Z"
Resource="gsiftp://pcmdi3.llnl.gov:2811/tmp/test.txt" Version="2.0">
<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:NameID Format="urn:esg:openid">https://pcmdi3.llnl.gov/esgcet/myopenid/rootAdmin</saml:NameID>
</saml:Subject>
<saml:Action xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">read</saml:Action>
</samlp:AuthzDecisionQuery>
</soap11:Body>
</soap11:Envelope>
<?xml version="1.0" encoding="UTF-8"?><soap11:Envelope xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
<soap11:Body>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="8f867708-529b-498c-a9de-c64f200f1ce2" InResponseTo="7658c723-7aef-478c-badf-c6cee670761f" IssueInstant="2010-03-11T23:04:23.167Z" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectName">CN=esg-cet.ucar.edu, OU=Services, DC=doegrids, DC=org</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="1038feda-9958-43e1-a00f-4696b572faa5" IssueInstant="2010-03-11T23:04:23.846Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectName">CN=esg-cet.ucar.edu, OU=Services, DC=doegrids, DC=org</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:esg:openid">https://pcmdi3.llnl.gov/esgcet/myopenid/rootAdmin</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2010-03-11T23:04:23.846Z" NotOnOrAfter="2010-03-12T23:04:23.846Z"/>
<saml:AuthzDecisionStatement Decision="Indeterminate" Resource="gsiftp://pcmdi3.llnl.gov:2811/tmp/test.txt">
<saml:Action>Read</saml:Action>
</saml:AuthzDecisionStatement>
</saml:Assertion>
</samlp:Response>
</soap11:Body>
</soap11:Envelope>
- Version number: 1.1
- Date: 10/14/2010
- Author: 1. Rachana Ananthakrishnan, Argonne National Laboratory
- Contributors: 1. Luca Cinquini, Jet Propulsion Laboratory 2. Phil Kershaw, The Centre for Environmental Data Archival, STFC Rutherford Appleton Laboratory 3. Neill Miller, Argonne National Laboratory
- Is the data node manager a component that is internal to the data node or should be part of this component?
- Similar question on publisher service?
-
SAML 2.0 Specification http://saml.xml.org/saml-specifications
-
SAML 2.0 Assertion Query Profile http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
-
OpenID 2.0 Specification http://wiki.openid.net/OpenID_Authentication_2
-
OpenID Attribute Exchange 1.0 Specification http://openid.net/specs/openid-attribute-exchange-1_0.html
-
Yadis http://yadis.org