On Becoming a VO SP

Overview

This topic discusses what it means to become a VO Service Provider (VO SP).

  • How can a VO SP obtain attributes, in particular, federation attributes?
  • What are the trust and policy implications of becoming a VO SP?

Terminology

$ Virtual Organization: A virtual organization (VO) is a list of users and a federated set of distributed resources made available to those users.
$ VO Service Provider: A VO service provider (VO SP) is a VO resource protected by a Shibboleth SP, that is, one of the distributed resources mentioned above.
$ VO Identity Provider: A VO SP makes Shibboleth.AuthnRequests to one and only one VO identity provider (VO !IdP). The VO !IdP is sometimes called the myVocs !IdP.
$ Federation Identity Provider: A federation identity provider is an !IdP willing to issue assertions on behalf of VO users.
$ Attribute Release Policy: An attribute release policy (ARP) governs the release of attributes at the !IdP. In Shibboleth, ARPs exist on a per-SP basis.
$ Attribute Acceptance Policy: An attribute acceptance policy (AAP) governs the acceptance of attributes at the SP.

General Use Cases

There are two use cases under consideration, corresponding to whether or not the VO SP is a federation SP. If the VO SP is not a federation SP, presumably it arises spontaneously from a desire or need to provide resources to some emerging VO. In this case, since no trust relationships with federation IdPs exist, there is no a priori reason for the VO SP to trust federation attributes. Thus we ignore this use case in what follows.

On the other hand, in the case where a federation SP wishes to become a VO SP (i.e., provide resources to some VO), we can do more since the VO SP already has established trust relationships with federation !IdPs. Consequently, both the federation !IdP and the VO SP have policy in place that governs the release and acceptance of federation attributes. It is this use case that we are concerned with here.

A Specific Use Case: The Internet2 Confluence Use Case

Mike !LaHaye, Internet2 Technical Services Director, discussed a relevant use case at a recent Internet2 Workshop.

Alternative Architectural Designs

There are at least three ways for a VO SP to obtain federation attributes:

  1. Attribute Aggregation
  2. Distributed Attribute Queries
  3. Attribute Request Proxy

Each of these approaches is discussed in more detail in the following sections.

Attribute Aggregation

The myVocs SP queries for federation attributes independent of the VO SP.

Suppose the attribute requirements of the myVocs SP are the union of the attribute requirements of all VO SPs. Since the VO SP trusts the VO !IdP, the latter can broker federation attributes on behalf of the VO SP. In this case, federation attributes are aggregated by myVocs and returned alongside VO attributes at the time of request. Since the VO SP trusts the VO !IdP, and the VO !IdP trusts the federation !IdP, the VO SP trusts the federation attributes brokered by myVocs. This is the notion of transitive trust that Main.JillGemmill often refers to.

I claim that transitive trust is fraught with difficulty. For instance, the federation !IdP has an attribute release policy (ARP) for the myVocs SP and another ARP for the VO SP, but these ARPs most likely do not coincide, so myVocs will generally be unable to obtain the attributes required by the VO SP. In other words, there is a policy mismatch between what the myVocs SP obtains and what the VO SP requires.

Distributed Attribute Queries

The VO SP queries for federation attributes independent of myVocs.

An alternative approach is to let the VO SP formulate its own attribute query. To do so, it needs to have two things: 1) a globally unique (persistent) identifier for the principal, and 2) a globally unique identifier for the principal's preferred !IdP.

The first requirement is easily satisfied. Currently, myVocs relies on Shibboleth.EduPersonPrincipalName (ePPN) for principal identifiers, which works fine in this scenario. Main.NateKlingenstein has argued eloquently for eduPersonTargetedID (ePTID) in lieu of ePPN, and I agree, but the implementation of ePTID is currently broken in Shib 1.3, so we should stick with ePPN for the time being.

The second requirement is more difficult. The providerId of the federation !IdP is contained in the authentication assertion issued by the !IdP, but this assertion is not available to the VO !IdP (and therefore not to the VO SP), and even if it were, it would contain a transient name identifier of little use to the VO SP. It is therefore futile to design a profile predicated on the availability of the original authentication assertion.

Suppose on the other hand that the VO !IdP formulates an authentication assertion as follows:

  • The value of attrribute AuthenticationStatement/@AuthenticationMethod indicates that the authentication act was performed indirectly by a federation !IdP (details TBD).
  • The NameIdentifier element contains the principal's ePPN.
  • The value of attribute NameIdentifier/@Format indicates that the name identifier is an ePPN (details TBD).
  • Attribute NameIdentifier/@NameQualifier is set to the providerId of the federation !IdP.

Now the VO !IdP pushes this authentication assertion and a VO attribute assertion to the VO SP. The VO SP consumes both assertions, observes the value of the AuthenticationMethod attribute, and passes control to the attribute requester despite the fact that an (VO) attribute assertion has already been consumed.

Alternatively, if the VO !IdP were to return an attribute that contained the providerId of the principal's !IdP, the VO SP could formulate an attribute query to the !IdP possessing this providerId. After all, the VO SP trusts the federation !IdP, and moreover it has already consumed federation metadata needed to formulate the query. We call this approach "Attribute Query Redirect".

Attribute Request Proxy

The myVocs SP queries for federation attributes on behalf of the VO SP.

To summarize, the myVocs SP can be configured to make an attribute query on behalf of the VO SP. Essentially, the myVocs SP impersonates the VO SP so that the federation !IdP returns attributes targeted at the VO SP. The myVocs SP blindly forwards these attributes (via the myVocs !IdP) to the VO SP for consumption.

Briefly, here's how this works. When a user makes a request for a resource protected by a VO SP, say, the GridShib CA, the client is redirected to the myVocs !IdP with the following Shibboleth.AuthnRequest (suitably formatted for readability):

https://sso.myvocs.org/shibboleth-idp/SSO?
  shire=https://computer.ncsa.uiuc.edu/Shibboleth.sso/SAML/POST&
	 providerId=https://test-sp.ncsa.uiuc.edu/shibboleth&
		target=cookie

where the target is the location of the GridShib CA (not shown).

Now since the myVocs !IdP is protected by the myVocs SP, under normal circumstances the client is redirected to the WAYF as follows:

https://wayf.internet2.edu/InQueue/WAYF?
  shire=https://sso.myvocs.org/Shibboleth.sso/SAML/POST&
	 providerId=https://sso.myvocs.org/shibboleth&
		target=cookie

where the target is the original Shibboleth.AuthnRequest above. To impersonate the VO SP, however, the myVocs SP substitutes the providerId of the VO SP in lieu of its own providerId in the Shibboleth.AuthnRequest:

https://wayf.internet2.edu/InQueue/WAYF?
  shire=https://sso.myvocs.org/Shibboleth.sso/SAML/POST&
	 providerId=https://test-sp.ncsa.uiuc.edu/shibboleth&
		target=cookie

As a result, the federation !IdP returns attributes targeted for the GridShib CA (subject to policy). These attributes are forwarded to the GridShib CA "as is," without processing of any kind.

The following thread in shibboleth-users mailing list discusses this solution in more detail:

https://mail.internet2.edu/wws/arc/shibboleth-users/2006-05/msg00147.html

An Example

This real-world example involving a recent workshop is a good example how NOT to bring up a VO:

  • When the administrative secretary registered me for the workshop, she provided my NCSA e-mail address, which was used by the workshop as my identifier henceforth. (Note, however, that there is no !IdP that will assert my NCSA e-mail address, nor is my NCSA e-mail address a real e-mail address, it is just a forwarding address.)
  • I was automatically subscribed to a mailing list using my NCSA e-mail address, which of course prevented me from posting to the mailing list since I use gmail.
  • I was given access to the workshop wiki with username equal to my NCSA e-mail address (wrong identifier) and global password (no security). Moreover, I was not able to access the workshop pages initially because I was not included in the appropriate wiki group (due to human error).
  • There appeared to be no real access control in the wiki. For instance, anyone was able to upload a file to the official workshop document store.
  • I was given access to the local wireless network with an ad hoc username/password on a yellow sticky note (instead of my institutional username/password).

Can myVocs help bring up this VO so that the above problems are avoided?

  • No labels