Single Sign-On in In-VIGO: Role-based Access via Delegation Mechanisms Using Short-lived User Identities

Sumalatha Adabala, Andréa Matsunaga, Maurício Tsugawa, Renato Figueiredo, José A. B. Fortes ACIS Laboratory, University of Florida, Gainesville, Florida

1-352-392-4964 / adabala, ammatsun, tsugawa, renato, fortes@acis.ufl.edu Abstract

Single Sign-On (SSO) is an essential desired feature of computational grids. Its implementation is challenging because resources cross administrative domains and are managed by heterogeneous access schemes. This paper presents an approach for Single Sign-On in a deployed functioning grid called In-VIGO. The approach relies on decoupling grid user accounts from local user accounts and making use of role-based access control lists. Role-based accesses via delegation mechanisms using short-lived user identities enable In-VIGO to handle interactive applications and application-specific authentication mechanisms. This capability is not present in existing grid architectures. SSO implementations for usage scenarios in In-VIGO are described to highlight the applicability of the proposed approach. In particular, access to interactive applications with their own security mechanisms, such as VNC, and access to remote data can be achieved using proxies that delegate In-VIGO user access via short-lived user identities. 1. Introduction

One of the main goals of grid computing is to "enable the sharing, selection, and aggregation of a wide variety of geographically distributed computing resources" [1]. Grid resources typically span administrative domains managed by independent authentication and authorization schemes and policies. Single Sign-On (SSO) allows grid users to access all authorized services and resources seamlessly, on the basis of a single authentication that is performed when they initially access the grid. Since the user has to remember only one username/password, and needs to type this information once, user productivity is improved and security breaches due to user behavior, such as users writing down their passwords, are eliminated. Automated access to authorized services and resources, managed by independent authentication systems without user

interaction also greatly improve the performance and transparency of grid middleware.

Support for SSO in existing grid security architectures is based on:

• Delegation of user credentials, e.g. proxy credentials with GSI [2], which map directly to local credentials on resources

• Mapping user credentials to "capabilities", e.g. restricted proxies with CAS [3][4] or resource claims with Secure Highly Available Resource Peering (SHARP) [5], which in turn are mapped to local credentials on resources.

• All participating sites/entities developing trust channels to share user credential information, e.g. .NET Passport [5] and the Liberty Alliance approach.

Representation of grid user identity information, which is typically based either on username/password pairs (e.g. .NET Passport [6]) or PKI-based credentials [2][3][4][5], is uniform within each of the above SSO approaches, but is not consistent across them.

Virtual computation and information grids such as In-VIGO (the acronym stands for In-Virtual Information Grid Organizations) provide users with services that access virtual resources, which consist of machines, data, applications and networks that are distributed across administrative domains, as well as grids managed by different SSO schemes. This paper presents a novel approach to support SSO in such virtual grids, to enable seamless access to authorized entities as varied as machines, data, applications, networks, and SSO-enabled grids in a uniform manner. It is based on the realization that in virtual grids users do not “own” resources and their information and computation needs are serviced by transient/virtual entities that meet their quality of service requirements. This allows an approach based on Role-Based Access Control (RBAC) [7], where principals who access entities are grouped into "roles", while "procedures" or "permissions" that describe access policies are defined on the entities, and permissions assigned to

roles enable authorization. The virtual grid middleware maps the credentials of a principal to a role, and accesses entities on behalf of the role, via short-lived identities that proxy the role’s permissions and are directly authorized by the entity. The translation between the roles and short-lived proxy identities is handled by the middleware, and this decoupling implies that the proposed approach is not tied to any user credential representation or resource access scheme. Finally, with hierarchical rather than system-wide namespaces for roles, mapping between role namespaces of similar principals, provides an elegant solution to overlaying underlying entities.

The proposed approach is currently being implemented and evaluated in In-VIGO [11]. User credentials are maintained as username/password pairs, and SSO support in the In-VIGO middleware enables users to:

• Invoke tool executions on GSI-enabled and SSH-enabled resources, via the platform dependent authentication mechanisms, by mapping user roles to UNIX accounts, which can be recycled shadow accounts [7] or temporary accounts created on demand for a job.

• Access data via filesystem-dependent authorization mechanisms, by using middleware-controlled distributed filesystem proxies [9] that map the short-lived IDs of the jobs running on behalf of the users to their remote data.

• Access applications that implement their own authentication mechanism, via proxies that provide temporary credentials on behalf of the user.

Further, mapping between In-VIGO user roles makes it possible to overlay multiple In-VIGO portals and other portals.

The rest of the paper is organized as follows: Section 2 sets the context for this work, including motivation and related work, with an overview of In-VIGO, a virtual grid architecture; Section 3 describes the authentication and authorization scheme for enabling SSO in virtual grids; Section 4 describes the implementation of the proposed approach in In-VIGO; Section 5 evaluates the proposed approach; and finally Section 6, concludes this paper and outlines future work.

2. In-VIGO Overview

In-VIGO is an information grid that allows users to run

tools in science and engineering on distributed grid resources. Once a user signs onto In-VIGO via a web browser interface, access to distributed resources/entities, i.e. machines, data, networks and applications, initiated due to user actions and requests is managed by the In-VIGO middleware. Accesses to these resources/entities, which may be distributed across administrative domains, are managed by site-specific authentication and

authorization schemes and policies. In order to make SSO possible, In-VIGO middleware must translate the privileges associated with a user action/request to the local privileges required to access the resources. 2.1. Virtualization in In-VIGO

The In-VIGO approach, as depicted in Figure 1, is to add three layers of virtualization to the traditional grid computing model. These virtualization layers hide implementation specifics in lower layers, and allow grid-wide operations that would be impossible otherwise.

The first virtualization layer creates pools of virtual resources that are the “primitive” components of a virtual computing grid, namely virtual machines, virtual data, virtual applications and virtual networks. This layer decouples the process of allocating applications to resources from that of managing jobs across administrative domains, physical machines and local software configurations.

In the second layer, grid applications are instantiated as services which can be connected as needed to create virtual information grids. This layer decouples the process of using and composing services from that of managing the execution of the underlying grid applications.

In the third layer, aggregated services (possibly presented to users via portals) export interfaces that are virtualized in order to enable displaying by different access devices. This layer decouples the process of generating interfaces of services from the process of rendering them on specific devices.

2.2. Motivation for Delegation via Short-lived

User Identities and Related Work

SSO offers benefits such as simpler administration, better administrative control, improved user productivity, better network security, and consolidation of heterogeneous networks over multiple sign-on. In this section we present the requirements that motivate the proposed authentication and authorization scheme to enable SSO in In-VIGO.

Enabling SSO in grid environments by providing grid users with local user IDs on the resources has prohibitive administrative overheads due to large numbers of transient users. In In-VIGO, users do not “own” resources and their information and computation needs are serviced by transient/virtual entities composed of virtual networks, data, applications and machines that meet their quality of service requirements. This allows complete decoupling of the “grid user” from the “local user” on the resource. The In-VIGO middleware owns the resources, i.e. has local identities on the resources, which are recycled among grid users, i.e. local identities are mapped to grid users for the

Figure 1: High-level view of In-VIGO architecture.

duration of resource use. Thus for example, an In-VIGO user does not have an account in any of the machines participating in the grid, and jobs are started by In-VIGO on behalf of the user using “local accounts” which could be recycled shadow accounts [8] or temporary accounts created on demand for a job.

One advantage of this approach is that a grid user is not required to be registered in all administrative domains, reducing administration tasks. Also once registered with In-VIGO, a user can potentially have access to all the grid resources available to In-VIGO.

SSO enabled by delegating the grid identity to a local identity via a direct mapping, such as access control list or capability list, has high administrative overheads, due to lack of flexibility, e.g. when updating access privileges, and scalability, e.g. when adding new users and resources. In In-VIGO role-based access delegation mechanisms are used to avoid such overheads.

Another benefit of decoupling grid identities from local resource-specific identities is that SSO in In-VIGO is not tied to any user credential representation or resource access scheme. This enables In-VIGO to provide users with interactive access to unmodified applications that

implement their own authentication mechanisms (e.g. Virtual Network Computing [10]), as well as other SSO-enabled grids.

The infrastructures offered by the projects listed below can be integrated into In-VIGO and be used for SSO. It should be noted that none of them offer a complete solution that meet the requirements of In-VIGO:

• Secure Highly Available Resource Peering (SHARP) [5] is a framework for distributed resource management across trust domains in a planetary scale grid. It supports resource “claims” based on cryptographically protected records, which assert that specified principals control some resources over designated time intervals, along with secure mechanisms to subdivide and delegate claims across a network of resource managers. Resource-specific site authorities redeem claims held by resource consumers by providing them with access to the required resources.

• Grid Security Infrastructure (GSI) [2] is an infrastructure based on public key encryption, X.509 certificates, and typically the Transport Layer Security (TLS) protocol [14] to authenticate and

Machines Applications Data Networks

Virtual computing grids

Virtual information grids

Service

Portal Portal PortalPortal

Service Service Service

Grid users

Virtual interfaces

Virtual Machines

VirtualApplications

VirtualData

Virtual Networks

authorize users to access resources, supporting delegation, identity mapping and single sign-on. Globus Toolkit version 3 (GT3) includes an implementation of GSI based on web services security protocols and standards [15]. It does not support application specific authentication (e.g. VNC), and grid user to local user mapping is limited to UNIX accounts. For policy enforcement across administrative domains, Community Authorization Service (CAS) [3][4] can be used.

• MyProxy [13] is an online credential repository for the grid that provides management of GSI credentials so that users do not need to worry about private keys and certificate files. For example, MyProxy allows grid portals to retrieve proxy credentials on behalf of a user, facilitating the use of grids for users holding credentials from multiple organizations. Since it only manages GSI credentials, MyProxy inherits the limitations of GSI.

• .NET Passport [6] is a SSO infrastructure developed by Microsoft that offers a web service based central authentication server, where participant sites can ask authentication service. It is only concerned with authentication, and does not offer any kind of user mapping.

• Shibboleth is a joint project of Internet2/MACE and IBM that aims to develop standards-based inter-institutional sharing and controlled access to services available via the web. The current version is implemented as an Apache web server module, and it is oriented to control access to documents available through the web server. Shibboleth focuses on inter-institutional collaboration, and leaves intra-institutional authentication responsibility to each organization. It requires resources to be accessible through web services, which rules out legacy applications (e.g. VNC).

All of these approaches rely on a uniform resource credential representation, so when resources or applications that implement their own authentication mechanism are integrated, the resources and applications must either be modified, or gateway services that translate credential representations must be implemented. 3. SSO in In-VIGO: Authentication and

Authorization Infrastructure

The authentication and authorization infrastructure in In-VIGO must provide users with SSO access to services composed of virtual resources, machines, data, applications and networks that span administrative domains, as well as other SSO-enabled grids/services in a uniform manner. This is enabled by completely decoupling In-VIGO user identities from the local

identities that are authenticated and authorized by site- or platform-specific schemes, and access resources on behalf of users’ actions. This decoupling is achieved by using RBAC mechanisms to group users and enforce the access policies of resources. 3.1. Roles of User Actions

Within the RBAC framework, In-VIGO principals, i.e. users or actions initiated by users, are grouped into one or more roles. Roles are a collection of permissions or procedures defined on In-VIGO entities, i.e. resources like machines, data, applications, networks or collections of resources like grids. For example, the role tool_X_machine_Y_licensed_users groups users with the permissions, such as software license, to run a tool X on machine Y. The In-VIGO administrators and tool installers define one or more role entry conditions, i.e. which users and user actions can enter a role, and how roles interact. The role associated with a user or user action, may be explicitly selected by the user or implicitly associated with an action initiated by the user. For example, a user may select to run a job on a machine Y, and as a result the role machine_Y_users is assigned to the job, else the user may specify QOS (memory and processing) requirements for his job that match the available resources on machine Y, and as a result the job is assigned the role machine_Y_users. When role entry conditions are conflicting, the role that denies access overrides others in accordance with the principle of least privilege. Thus for example, if a user can belong to a role, access_all_machines, that allows access to all machines at a site, but also belongs to a role, deny_access_subset_X_machines, that is denied access to a subset of machines at the same site, then an action initiated by him is allowed access to any of the machines other than those he is denied access to. Role hierarchies are allowed, i.e. one role can inherit from another. In the previous example, a new role access_subset_Y_machines, that inherits from roles access_all_machines and deny_access_subset_X_machines can be defined to describe users who can access machines other than the subset X of machines at the site. Role namespaces are hierarchical, i.e. each entity that defines roles has its own namespace. This is simpler than trying to enforce a single In-VIGO wide namespace for all roles defined on various resources, by resource-specific administrators. Thus for example the role machines:tool_X_users defined on the entity ‘machines’, groups users with access to machines with tool X installed, and is distinct from the role applications:tool_X_users defined on the entity ‘applications’, which groups users with permission to run tool X.

3.2. Permission Groups: Describing Access Policies of Entities

Permissions or procedures are access operations

defined on the entities/resources in In-VIGO. These can be mapped to access policies that are implemented and enforced by resource-specific authorization schemes. The mapping of roles to permission groups is implemented by the In-VIGO administrator and middleware. For example, a permission group large_data_sets defined on a simulation tool Y describes the operation of running the tool Y with large data sets. In order to allow research users to run simulations with large data sets, the administrator can define a user role (e.g. research_users) that maps to the large_data_sets permission group. 3.3. Short-lived Identities

Each permission group, or sets of permission groups defined on a resource or entity are associated with one or more local identities, “owned” by the In-VIGO middleware, on the resource or entity. These local identities have the access privileges that match the resource access privileges defined by the permission groups. The security component of In-VIGO middleware maps user roles to permission groups, which in turn are mapped to local identities on a given resource. Delegation is accomplished by accessing resources via the local identities on behalf of the In-VIGO user. This is typically enabled by proxies or services in the middleware that provide resources with the local identities for authentication and authorization. The local identities may be recycled among users, or created temporarily on-demand. Local identities or credentials may be capabilities, e.g. restricted GSI proxies, SHARP resource claims, or username/password pairs, e.g. .NET username and password, to access the resource, so this approach does not tie into a resource access scheme and resources managed by other grid security infrastructure can be integrated into SSO in In-VIGO without any modifications. 4. Implementation

Virtualization in In-VIGO creates environments for the

applications to run without modification. In some cases, to achieve this goal, the In-VIGO virtualization layer needs to create proxies. These proxies enable In-VIGO middleware to use short-term IDs and offer SSO to end users. The current implementation of In-VIGO supports the following scenarios:

• Namespace mapping. • Mappings via proxies and short-term IDs.

4.1. Namespace Mapping

Namespace mapping in In-VIGO is implemented in the information system layer, exchanging user information with other portals. For example, In-VIGO can accept and authenticate users coming from the ACIS web site [12], where researchers have a workspace to discuss ongoing research. This is achieved by the role-based mapping information exchange between the In-VIGO information system and the ACIS web site user management layer, each of which has its own namespace, i.e. roles in In-VIGO hierarchy are distinct from roles defined in the ACIS hierarchy. A similar approach allows overlaying multiple In-VIGO portals over underlying resources. For example, In-VIGO developers access resources via their own instances of the In-VIGO portal by mapping user roles in the developer portals to roles in the main In-VIGO. 4.2. Role Based Access to Application

Functionality

Figure 2: A push model of authorization is used to implement RBAC of application functionality in In-VIGO. When an In-VIGO user starts a session by selecting an application and explicitly setting one or more user classes, the application session is created, and the user interface module of In-VIGO obtains the corresponding set of application permission groups from the application authorization service. Requests from the user along with the application permission groups, which serves as a capability, are directed to the application session by the user interface module.

Requestor (user)

(1) Request for authorization, i.e. user logs in

(2) User class list

Resource(Application)

Authorization service

Policy

(3) Session request + permission groups

Figure 3: Mapping (a) user X file system to shadow1@BE1 (private network scenario) and (b) user Y file system to shadow2@BE2 (scenario where communication is protected through tunneling) using VDFS proxies.

User privileges determine the functionality of applications accessible through In-VIGO. Thus a user with “researcher” privileges may be allowed to start parameter sweep jobs with a simulator tool, while a user with “regular user” privileges may be allowed execute single jobs with the same tool. RBAC of applications is achieved by mapping users into one or more “user classes”, i.e. roles, and assigning application “permission groups” to roles, where permission groups predicate application functions/features. 4.3. Proxies to Authenticate and Authorize Short-

term IDs 4.3.1. Virtual Distributed File System (VDFS): Short-

term ID to User data mapping

In-VIGO uses shadow accounts in resources available in the grid to execute grid user jobs. Since shadow accounts are recyclable, they need to have access to data belonging to any grid user. However, no shadow account should have access to grid user data other than that owned by the user assigned to the shadow account.

VDFS provides the necessary isolation between users in regard to data access, allowing a shadow account (short-term ID) to have access to user data. If user data is needed across administrative or physical domains, thus traversing the internet, the privacy and session-key authentication

can be guaranteed by the use of secure tunnels for the necessary communication. 4.3.2. VNC: User to short-term ID mapping

Virtual Network Computing (VNC) [10] is a remote display system which allows users to view computing environments on the internet. VNC enables In-VIGO to offer applications that need a graphical user interface (GUI) to grid users. VNC is a client/server application: the VNC server receives keyboard and mouse inputs from the VNC client, and transmits display information.

The VNC server is started by In-VIGO using a shadow account. VNC client runs in the client browser (as an applet) driven by the grid user. VNC server requires user authentication, so the grid user needs to be mapped to the shadow account (short-term ID) that is running the VNC server.

When starting VNC server, In-VIGO generates a random password, and sets appropriate credentials in a hidden place in the In-VIGO portal. In-VIGO only presents this location (containing credentials to authenticate to the VNC server) to the appropriate grid user. The grid user only needs to access this location to download the VNC client applet with the correct credentials.

File Server S1

BackEnd BE1

mount S1:/home/F/X

NFS client

Shadow account shadow1

SSH

Case (b) SSH channels

NFS server

VDFS proxy

export /home/F/X to shadow1@BE1

File account facc1

export /home/F/Y to shadow2@S1

VDFS SSH

BackEnd BE2

mount BE2:/home/F/Y

NFS client

Shadow account shadow2

Case (a)

Figure 4: VNC Single Sign-On in In-VIGO.

4.3.3. Collaborative environments: mapping multiple

grid users to short-term ID

The mapping of grid users to short-term IDs, as described in section 0, makes another interesting application possible: the virtual shared workspace.

By creating multiple credentials (one for each participant of a working group) to be accepted in VNC server authentication, In-VIGO can create a virtual environment where users can share a desktop.

The VNC server provides native support for shared devices, multiplexing the input (keyboard, output) from different clients, and multicasting the output (display) to each user’s client. The sharing of basic I/O devices for user interactivity can therefore be leveraged from the VNC-based setup described in 0. In addition, proxy-based mappings for virtual distributed file system mount points can complement this setup by providing mechanisms for dynamic many-to-one mappings of shadow accounts (short-term user ID) to file accounts (data repositories), enabling collaboration also to take place across user file systems.

5. Evaluation

• Feasibility and Deployability: all case scenarios presented in this paper are successfully being used in the deployed In-VIGO system.

• Authentication Security Strengthening: the authentication mechanism of the original underling system is maintained and in some cases it is strengthened because short-term credentials are seamlessly created in behalf of the user in a way that the user does not need to repeatedly type or keep different passwords.

• Granularity and Extensibility: In-VIGO is able to provide finer-grain resource access control than existing solutions since all primary resources (machines, applications, data, and networks) can be separately accessed; In-VIGO allows policies to be flexibly and extensively defined.

• Privacy considerations: In-VIGO uses “shadow accounts” when running jobs in grid resources. Only the In-VIGO resource management layer knows the mapping between grid users to “shadow accounts”. Also, in some cases, In-VIGO encapsulates “shadow accounts” in a virtual resource. In this environment, grid users do not have a way of knowing what other grid users are doing.

• Accountability: while maintaining good privacy between grid users, In-VIGO resource management can keep track of all actions requested by a user and all jobs successfully executed.

6. Conclusions and Future Work

This paper describes a security architecture to enable SSO for virtual grids that uses delegation mechanisms via short-lived user identities to uniformly support diverse resource access schemes, and role-based access to decouple users from resource policy providers. Case studies of SSO support for grid usage scenarios in the context of In-VIGO were presented.

In the current implementation, mapping of users to roles and mapping of roles to permissions are created and maintained in a non-standard format, in a centralized information system by the In-VIGO administrator. Future work will look at existing standard formats such as SAML for managing the information. The security component that implements this mapping currently provides a Java

Web

Browser

Request (HTTPS)

HTML

User Web Server

VNC Server

VNC Web

Server

VNC Applet

Request (HTTP)

HTML

Port Forwarding

VNC protocol

VNC protocol

Public network Private network

Apache

(Reverse proxy)

In-VIGO Backend

based API to other implicitly trusted components of the In-VIGO middleware. This component can be implemented as a secure grid service. The language and platform independence enabled by this will allow grid middleware, other than In-VIGO, to leverage the proposed SSO approach. Caching of the short-lived IDs maybe required to amortize the overheads introduced by the grid services approach. On-going research is investigating these aspects. 7. Acknowledgements

This material is based upon work supported by the National Science Foundation under Grants No. EIA-9975275, EIA-0224442, ACI-0219925, EEC-0228390 and NSF Middleware Initiative (NMI) collaborative grants ANI-0301108/ANI-0222828, and by the Army Research Office Defense University Research Initiative in Nanotechnology. The authors also acknowledge two SUR grants from IBM and a gift from VMware Corporation. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation, Army Research Office, IBM, or VMware. References [1] Grid Computing Info Centre,

<URL:http://www.gridcomputing.com>. [2] R. Butler, D. Engert, I. Foster, C. Kesselman, S. Tuecke, J.

Volmer, and V. Welch, “Design and deployment of a national scale authentication infrastructure”, IEEE Computer, 33(12):60-66, 2000.

[3] Pearlman, L., Welch, V., Foster, I., Kesselman, C., Tuecke, S., “The Community Authorization Service: Status and Future”, CHEP 2003.

[4] Pearlman, L., Welch, V., Foster, I., Kesselman, C. and Tuecke, S., “A Community Authorization Service for Group Collaboration”, IEEE 3rd International Workshop on Policies for Distributed Systems and Networks, 2002.

[5] J. Chase, B. Chun, Y. Fu, S. Schwab, and A. Vahdat, “Sharp: An architecture for secure resource peering”.

[6] Microsoft, “Microsoft .NET passport – Review Guide”, June 2003, <URL: http://www.microsoft.com/net/services/passport/review_guide.asp>.

[7] J. Barkley, “Comparing Simple Role Based Access Control Models and Access Control Lists”, Proceedings of the Second ACM Workshop on Role Based Access Control, November 1997.

[8] R. J. Figueiredo, J. A. B. Fortes, R. Eigenmann, N. H. Kapadia, S. Adabala, J. Miguel-Alonso, V. Taylor, M. Livny, L. Vidal, and J. Chen, “A Network-Computing Infrastructure for Tool Experimentation Applied to

Computer Architecture Education”, Workshop on Computer Architecture Education at the 27th Annual International Symposium on Computer Architecture (ISCA'2000), June 2000, Vancouver, Canada.

[9] R. J. Figueiredo, N. H. Kapadia, and J. A. B. Fortes. “The PUNCH virtual file system: Seamless access to decentralized storage services in a computational grid”, In Proceedings of the 10th IEEE International Symposium on High Performance Distributed Computing (HPDC'01), San Francisco, California, August 2001.

[10] T. Richardson, Q. Stafford-Fraser, K. R. Wood, and A. Hopper, "Virtual Network Computing", IEEE Internet Computing, Vol. , No. 1, 1-2/1998.

[11] The In-VIGO Portal <URL:http://invigo.acis.ufl.edu>. [12] The ACIS web site <URL:http://www.acis.ufl.edu>. [13] J. Novotny, S. Tuecke, and V. Welch, “An Online

Credential Repository for the Grid: MyProxy”, Proceedings of the Tenth International Symposium on High Performance Distributed Computing (HPDC-10), IEEE Press, August 2001.

[14] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999, <URL:ftp://ftp.ietf.org/rfc/rfc2246.txt>

[15] V. Welch, F. Siebenlist, I. Foster, J. Bresnahan, K. Czajkowski, J. Gawor, C. Kesselman, S. Meder, L. Pearlman, and S. Tuecke, “Security for Grid Services”, Twelfth International Symposium on High Performance Distributed Computing (HPDC-12), IEEE Press, June 2003.

[16] M. Erdos and S. Cantor, “Shibboleth-Architecture DRAFT v05”, May. 2002, <URL: http://middleware.internet2.edu/shibboleth/docs/>.