Any functionality or implementation detail not specified herein is left to the discretion of the appropriate entity.

Definitions

Proxy Authentication Server

A server willing to proxy authentication requests and issue limited use credentials upon successful authentication.

Attribute Verification Server

A server willing to answer specific authorization queries upon presentation of valid credentials. This server may physically be the same host as the Proxy Authentication Server.

Provider Site

A participating site that has content to be shared.

Auth Site

A participating site that has a member wishing to access material at a provider site.

General Purpose Credential

Any identifier or mechanism used by the Proxy Authentication Server to eliminate the need for a user to reauthenticate when redirected to the Proxy Authentication Server multiple times in a single session.

Specific Validation Credential

An identifier returned by the Proxy Authentication Server to the Provider Site which may be used by the Provider Site to verify the identity of the Auth Site member.

Requirements

1. Be found via a DNS SRV record, using the service name iraapas.
2. Operate over HTTPS.
3. Support a login URL at /iraa/login?service=name
   [&user=username][&validfor=servicelist|¬validfor=servicelist]
   [&gpcuses=num][&expiry=time][&svcuses=num][&valexpiry=time][&passwdage=days]&destination=URL
   
   • name: Identifier for the service requesting authentication. This value need not directly correspond to the URL. Some provision for strongly authenticating service names may be added later for optional benefits. The names self, none, and any are reserved. Implementation of this flag is optional.
   • username: Username that may identify the user who is authenticating, if the provider site already knows it. Implementation of this flag is optional. If implemented, it must be treated as advisory only.
   • servicelist: A list of service names (as defined above) that may be used to restrict the purpose of any general purpose credentials issued at login time. The list may be one or more comma separated names, or any one of the special names: self, none, or any. Implementation of this flag is optional. If implemented, the proxy authentication server may choose to modify the request for any reason.
   • num: A number to restrict the number of uses of any general purpose credentials issued (gpcuses) or a number to restrict the number of times a specific validation credential may be validated (svcuses). By default, a specific validation credential may only be validated once. Implementation of this flag is optional. If implemented, the proxy authentication server may choose to modify the request for any reason.
   • time: An integer indicating the number of seconds from the time of successful authentication that the general purpose credentials are valid for or the number of seconds from the time of successful authentication in which the validation must occur.
   • days: An integer indicating the number of days from last password change when service requires the password to be changed. If the password has "expired" for the service, other services may still consider it valid. Implementation of this flag is optional.
   • URL: URL to redirect back to when login attempt has completed. The URL will be appended with ?ticket=opaque-string. In order to prevent ambiguous parsing situations, the return tag must be last.
4. Support a validation URL at /iraa/validate?ticket=opaque-string&service=name
   
   • opaque-string: The ticket value passed back to the URL specified to the login URL.
   • name: The identifier for the service requesting authentication. This value must match the value passed to the login URL.
   • The response is in YYNP format: a text/plain HTTP response where the first line of this reponse is either "yes" or "no", indiciating a valid or invalid credential. If valid, the second line of this response contains an identifier of the authenticated user. This identifier may be any one of the following:
     1. The local identity of the user.
     2. An encrypted, persistent identifier that can be uniquely traced back to the user by the Auth Site, or that may be tracked (and thus a profile created) by the Provider Site. The Auth Site may generate different persistent tokens for different provider sites.
     3. A random, single use identifier that may be traceable by the Auth Site, but can not be used by the Provider Site to create a profile.
     There is no indication in the response as to which type of identifier is returned.
5. Support a logout URL at /iraa/logout. This operation must destroy any unusued validation credentials. Additionally, if the proxy authentication server issued general purpose credentials, those must be expired.

1. Be found via a DNS SRV record, using the service name iraaavs.
2. Operate over HTTPS.
3. Support an authorization URL at /iraa/authorize?ticket=opaque-string&service=name
   &authz=authzquery
   
   • opaque-string: The ticket value passed back to the URL specified to the Proxy Authentication Server login URL.
   • name: The identifier for the service requesting authentication. This value must match the value passed to the Proxy Authentication Server login URL.
   • authzquery: This flag indicates the specific authorization or authorizations the Auth site would like to verify. The query must consist of exactly one of the following:
     1. memberofany+affiliation[+affiliation...]: Determine if the user in question is a member of at least one of the affiliations provided. Examples:

             memberofany+student.columbia.edu
             memberofany+student.columbia.edu+faculty.columbia.edu
             

     2. memberofall+affiliation[+affiliation...]: Determine if the user in question is a member of all the affiliations provided. An example looking for all students enrolled in both the Business School and the Law School:

             memberofall+gsb.student.columbia.edu+law.student.columbia.edu
             

     3. whichof+affiliation[+affiliation...]: Determine which (if any) of the affiliations provided are the user in question has. Example:

             whichof+student.columbia.edu+faculty.columbia.edu+staff.columbia.edu
             

     4. profile+format: Obtain all affiliations for the requested user. It is expected that few, if any, Provider Sites will have permission to issue this query. format indicates the format of the response, which is expected to include LDIF and XML.

     5. default: Obtain the default query for the site making the request. It is up to the server to determine how to respond to this query for each site, or whether or not to support it.

     See the documents section of this page for more details on the format of affiliations. The Attribute Verification Server may determine which queries to answer conclusively according to site and/or user preferences.

   • The response is in extended YYNP format (except for the profile operation, which is in the format requested): a text/plain HTTP response where the first line of this response is either "yes" or "no", indicating a valid or invalid credential. If valid, the second line of this response contains an identifier of the same format as issued by the Proxy Authentication Server. If valid, for memberofany and memberofall requests, the third line will consist of an additional "yes" or "no" response, indicating whether the requested affiliations were found. If valid, for whichof requests, each matched affiliation will be listed one per line beginning with the third line of the response.

1. Provide an IRAA! compliant module for its web server to control access to static pages, or gateway static requests using an IRAA! compliant proxy, if interrealm access to static pages is desired.
2. Modify dynamic content providing programs (CGIs) to be IRAA! compliant, or gateway access via an IRAA! compliant proxy, if interrealm access to dynamic content is desired.

1. Provide an IRAA! compliant Proxy Authentication Server.
2. Provide an IRAA! compliant Attribute Verification Server.

Process

1. A user from an auth site visits a provider site.
2. The provider site asks the user for their email address or the name of the domain from which they come (perhaps defaulting to the domain the connection originates from). Using the domain provided, or the domain extracted from the email address, the provider site performs DNS SRV lookups to discover the locations of the visitor's proxy authentication server and attribute verification server.
3. The provider site redirects the visitor's browser to his or her proxy authentication server.
4. The proxy authentication server authenticates the user and redirects the browser back to the provider site with a specific validation credential.
5. If the provider site only wishes to perform authentication, it verifies the credential against the proxy authentication server. If the site wishes to perform authorization, the site issues a query to the visitor's attribute verification server, passing the specific validation credential with the query.
6. Once the provider site satisfied, the document is returned to the visitor.

• A Specification for Formatting Affiliations in Institutions of Higher Education
• Example IRAA sessions for contracted content providers