To: dsml@lists.oasis-open.org
Date: Wed, 04 Apr 2001 21:13:06 -0700
Fast forward to March 2001 and we have three new contributions:
DAML http://lists.oasis-open.org/archives/dsml/200103/msg00003.html
DirXML http://lists.oasis-open.org/archives/dsml/200103/msg00004.html
XMLDAP http://lists.oasis-open.org/archives/dsml/200103/msg00001.html
Here is my brief summary:
DAML is an XML wire-level alternative to ASN.1 for LDAP. It's an interesting idea, and it could have saved many of us a lot of difficult debugging if it had been the wire protocol of choice for LDAP. But I'm not sure where it fits in with application-level access to directory data.
DirXML is a more extensive language along the lines of DSML 1.0 (but different) for representing directory entries and adopting the "operation as XML element" approach for representing directory operations. The submitted documents are HMTL versions of DTDs. It would be nice to have an overview, or a complete sample document conforming to the DTDs, but I think I see representations for all the LDAP operations referenced in DTD-TREE.html. I don't see how you can express a search other than exact match on an attribute value (e.g. no substring match), though. DirXML looks (from the submitted DTDs) like a schema for synchronization between an NDS directory and an application.
XMLDAP is an XML gateway to LDAP - not in itself an XML language for accessing directories. However it includes an XML tag library for acessing LDAP directories using another "operation as XML element" approach. XTL (XML Template Language, the language that includes LDAP access tags) is used to inject directory data into an XML document as part of page preparation (HTML, WML, other XML). XTL doesn't include an XML representation of directory entries.
3.3.2 WAYF
WAYF exports one distinguishable external interface:
- Discover Home Organization. With the user's intervention (or via a cached object from a previous user indication), identify the user's specified origin site and return the associated attributes to the requestor (usually the SHIRE).
3.3.3 Target
The target does not export any standard Shibboleth interfaces. However, processing on the target side can be decomposed into discrete units, in order to simplify discussion. The units of interest are:
- Obtain User Home Organization. Determine the User's Home Organization.
- User context establishment. The "SHIRE" functionality of associating an incoming client HTTP request with a query to be made to an AA to provide attributes. This can be done via client cert or making a Shibboleth get_Attribute_Query_Handle request (ie, function (1) above) to obtain a Shib-defined authentication object (ie, AQH).
- Attribute acquisition. The "SHAR" function of making a request to a Shibboleth attribute supplier (ie, function (2) above in 3.3.1).
- Resource Manager. (Note: this function is outside the scope of Shibboleth.) Make an access control decision for this user accessing this resource.
3.4 The Role of Sessions
In this document a "session" is state information established and maintained by a service to provide context for a series of operations. For Shibboleth the service is a web-based (ie, HTTP-accessed) application service, and the state information of most interest is security-related context. Typically, though not always, a service will provide its client with access to session-state management operations, including as initiating, modifying, or ending a session.
A browser user accessing a Shibboleth protected target resource is likely to create sessions at the origin site and at each target site:
- The origin site's Web SSO mechanism is likely to maintain a local session for the browser user. This session will exist outside of Shib, but Shib will leverage its existence. The first time the user visists a protected target resource they will likely be redirected back to the origin site Web SSO mechanism. The user will have to login. When the user visits other Shibboleth protected sites, they will still be redirected back to the origin site. However, because of their existing local session, they will not have to login again.
- At each target, the SHAR should maintain a session, in a manner consistent with the descriptions available in "Notes on Support of target web server sessions in Shibboleth". There are well established guidelines and tradeoffs when web servers and web applications maintain state. A browser user accessing multiple protected static resources at the same SHAR is likely to have an unacceptable usage experience if the SHAR does not maintain some session state. The referenced Notes section contains a discussion of various implementation options. However, the choice for a particular implementation is a design decision, best left to the implementors.
- A short lived assertion (the AQHR) will carry a pseudononymous reference (the AQH) from the origin to the target. The AQHR will likely have a short lifetime; the AQH is likely to have a longer lifetime.
3.5 Identifying the User
The Destination Organization needs a way to identify the browser user in conversations with the User Home Organization. Shibboleth has defined three ways for the DO to obtain the required context. All three result in the DO having an Attribute Query Handle (AQH).
The scenario is likely to be "user goes directly to the target". The target will know nothing about the user (beyond the IP address of the machine running the browser). In this situation, the SHIRE will 1) use the WAYF Service to have the user identify their origin site, and 2) use the get_Attribute_Query_Handle Message Exchange Sequence toobtain an AQH from the UHO.
Another scenario has the user clicking a link on a local navigation site, to take them to the target. The UHO would have pre-configured the link to contain an AQHR. The user arrives at the DO with all of the information that the SHIRE needs in order to successfully obtain an AQH and establish a session.
The last scenario has the user browser containing a [BLAH] certificate. When the user directly connects to the DO, the DO obtains the certificate from the browser. The certificate contains [BLAH] and SHIR does [BLAH].
3.6 The Attribute Authority
(site policies) (user policies) (controlled release of attributes)3.7 Glossary
- attribute query handle, AQH. An opaque user handle which the SHIRE can use to obtain attributes, and which the AA can map to the user's local attributes.
- Attribute Query Handle Response - a secure package for the attribute query handle
- Attribute Policy Store - entries control the release of attributes to target sites
- attribute release policy (ARP)
- attribute query message (AQM)
- attribute response message (ARM)
- redirection
- eduPerson
- FQDN
- NetID
- "Shibboleth standard attribute names and values"
4. Message Exchange Sequences
4.1 Obtain User Home Organization
(tbd)
needs to return a url for the Handle Service and (a cert, the PKI identity of the handle service being referred to)
4.2 get_Attribute_Query_Handle
| message direction | message type |
| SHIRE -> Handle Service | Attribute Query Handle Request |
| Handle Service -> SHIRE | Attribute Query Handle Response |
This message sequence is usually initiated by the SHIRE when a browser user arrives at the target and there is no handle information available that is associated with the request. Handle information might have been available if: 1) the browser user had previously visited this site and the SHIRE had created a session and assocaited the handle informaiton with the session, 2) the user arrived at the target by having clicked through a navigation site at their origin site which had associated a handle with the request before forwarding it, or 3) the browser had made available a client cert containing a handle. If any of these conditions are met, and the SHIRE's lifetime for the handle has not expired, then this message sequence is not needed.
In case two above, the navigation site is likely to generate the Response message without the SHIRE ever having created the Request message. This is considered a valid sequence, as long as the supplied AQHR passes the vlaidity checks done by the SHIRE. Consequently, the SHIRE can operate in a stateless fashion; there is no need for it to remember the requests that it has issued.
This exchange, by itself, does not provide the Destination Organization with any name or attribute information about the browser user. The Attribute Query Handle Response contains the Attribute Query Handle (an opaque reference to the browser user) and address information for the Attribute Authority which can provide information associated with this handle. The AQH has meaning only to that Attribute Authority.
The exchange consists of two messages: an Attribute Query Handle Request from the SHIRE to the Handle Service, and an Attribute Query Handle Response from the Attribute Authority back to the SHIRE. [Q: ANY ERRORS?] These messages are described in sections 5.1 and 5.2. Both messages flow through the user's browser by using the HTTP redirect function. This is the only transport binding allowed. The Handle Service (or its designees) are allowed to interact with the browser user before sending the Attribute Query Handle Response and redirecting the user back to the target. This interaction, if it occured, would typically involve a web-login style sequence.
To initiate the sequence, the SHAR should build a new URL and redirect the browser with this new URL. The protocol in the URL will always be HTTP. The hostname and port were returned during the Obtain User Home Organization sequence. There are three parameters passed with the URL.
- ShibCmd
- For this exchange, ShibCmd must always have a value of "GetHandle". This tells the Handle Service the function that is being requested. This parameter is required. (Yes, today there is only one function. In the future, there may be more.)
- target
- the target url presented by the browser, when it initially contacted the target site. This parameter is optional. Since this is used to redirect the user back to the original target once Handle Server processing is complete, it must be the entire original url, including all of the parameters. [HOW HANDLE POST/ GET]
- shire
- the FQDN of the SHIRE. This name must have been previously accepted as a member of "Club Shib". This parameter is required.
The Handle Server must perform the following functions before returning control:
- upon the user's arrival via redirection from a target, establish a security context with a user (ie the "weblogin" function). This may use an existing, external Web SSO mechanism at the origin site;
- establish an AQH;
- build an Attribute Query Handle Response (containing the AQH);
- redirect the browser back to the target site, appending the AQHR;
Many sites will want to use their existing Web SSO mechanism to authenticate the user, and will expect the get_Attribute_Query_Handle function to leverage this pre-existing service. There are many designs that can meet these requirements; some are described in [Q: BLAH]. If the user is unable to successfully authenticate, they are left at the web-login screen. There is no error return that is passed back to the SHIRE.
The Attribute Query handle (AQH) must 1) be an opaque handle, and 2) have meaning only to the Attribute Authority. It must be impossible for another entity to guess the identity of the user by using the AQH. There are many designs that can achieve opacity. Which one is chosen may depend on how issue two is addressed - how does the HS obtain an AQH that is only understood by the AA? This description has decomposed the User Home Organization into multiple functions, including the Handle Service and the Attribute Authority. However, a legitimate design might put both functions into the same program. This would solve the problem. Alternatively, the HS might use an SSL encrypted session with the AA, and have the AA generate the AQH and return it. The HS might use an SSL encrypted session with the AA, and tell the AA the NetID and AQH pair. The HS might seal the NetID with the public key of the AA, and consider the result to be the AQH; the AA would merely decrypt the AQH to obtain the user's NetID.
[AQH - same for every SHIRE?]
The Attribute Query Handle Response is a set of parameters that is appended to the redirection url that sends the user back to the target.
- AQHR_ver
- major and minor version number of AQHR format
- AQHR_handle
- the AQH that was generated
- AQHR_shire
- fully-qualified domain name of the requesting SHIRE (passed in the shire= parameter of the query)
- AQHR_ip
- IP address of browser process associated with handle
- AQHR_time
- AQHR issue time, in seconds since midnight 1/1/70
- AQHR_method
- comma-delimited list of AA binding methods/types; see section X
- AQHR_aa
- comma-delimited list of of AA binding strings
- AQHR_DNSname
- DNS name of the host which is signing the AQHR
- AQHR_sig
- Shib signature of digest
See "Notes on Signing".
The digest itself is not passed as aprt of the AQHR, which is a divergence in approach from the XMLSignature document, which specifies that the digest algorithm and value are passed alongside the signature algorithm and value. The reasoning for their decision is unknown.
The Handle Service must build a new url, and redirect the user back to the original target. The protocol will always be HTTP. The hostname, port, path, and parameters were the value of the "target" parameter on the Attribute Query Handle Request. The just built Attribute Query Handle Response is appended to the url.
The user arrives back at the original target. This time, however, the parameters that, taken together, constitute the Attribute Query Handle Response are appended to the URL. The SHIRE proceeds to validate the AQHR.
- AQHR_ver is supported
- AQHR_DNSname is contained in the subject field of the server cert used by the "sender"
- AQHR_DNSname is in the list of trusted speakers
- AQHR_time is very recent
- AQHR_ip is the address supplied by the browser
- AQHR_shire is the name of this SHIRE
The SHIRE should create a session for the browser user, and associate AQHR_handle with the session. [anything else?]. The SHIRE should set a lifetime for the use of the handle. [recommended lifetime?] The AQHR can be discarded at this point.
4.3 get_attributes
| message direction | message type |
| SHAR -> Attribute Authority | AQM |
| Attribute Authority -> SHAR | ARM |
| SHAR -> Attribute Authority | URL returned by AA |
| Attribute Authority -> SHAR | ARM |
This message sequence is usually initiated by the SHAR in order to obtain attributes about the user referenced by the Attribute Query Handle (AQH). The AQH refers to the browser user, and has been previously obtained by the SHIRE. The sequence always starts at the beginning; there is no way for the Attribute Authority to initiate the sequence in the middle of the message exchange. Previous requests from the browser user might have caused the SHAR to have cached attributes about this AQH; SHAR caching is discussed below.
The set of attributes that the AA gives to the SHAR is determined by policy in the AA. The SHAR cannot ask for specific attributes, or refuse to accept the attributes offered by the AA. The SHAR, in fact, has no way of determining whether the attributes provided by the AA are useful, relevant, appropriate, or sufficient to provide access. Once it has the attributes, the SHAR passes them on to the Resource Manager.
The message exchange consists of two required messages followed by two optional messages. The required messages can be transported using one of several different transport bindings. In most cases, the SHAR will use a transport that is out-of-band from the existing browser session. If the policy associated with the requested target specifies "real-time control of attribute release", then the AA will use the ARM to indicate this condition to the SHAR, and to return a URL to the SHAR. In this case, the SHAR should use this URL to initiate the optional two messages.
The two required messages are an Attribute Query Message (AQM) sent from the SHAR to the Attribute Authority, followed by an Attribute Response Message (ARM) returned from the AA to the SHAR. A previous message sequnce (get_Attribute_Query_Handle) returned a pair of values: AQHR_method (a comma-delimited list of AA binding methods/types) and AQHR_aa (comma-delimited list of of AA binding strings). The two values should contain the same number of list items. Item one in the methods list corresponds to item one in the aa list, and so forth. If there are multiple values in the list, the SHAR should interpret this to mean multiple ways of contacting the same AA, NOT as meaning that there are multiple AAs which can provide attribute information (possibly different attributes) about the user. The SHAR is free to choose any of the offered binding types that it supports. If the SHAR is unable to create a connection with its chosen binding type (and associated binding string), it should choose another binding type that it supports, and attempt another connection. It should continue doing this until it successfully establishes a connection. If the SHAR begins a message exchange and a problem occurs, or the SHAR "does not like" the response from the AA, it should terminate with an error, rather than attempting another connection.
Both the AQM and the ARM are XML formatted messages. The schema are available from [BLAH].
[Build the AQM]
Upon receipt of an AQM, the Attribute Authority performs the following processing. [verify the SHAR speaker].
The AA must map the AQH into a local identity. This is the reverse of the process initially performed by the HS, when it generated the AQH. The output of this process must be a reference to the set of attributes associated with a unique individual. The reference must be in a form that will allow queries to be made to the Attribute Repository. If the AQH cannot be successfully mapped into a local identity, then the AA must return a [BLAH error].
The AA must find the appropriate attribute release policy. The AA must use a "best fit" algorithm, looking for the SHAR and target combination in its policy database that best matches the corresponding fields in the query. If it is unable to make a match, then the AA should return an error. This may be an unlikely occurance, though, because many sites may enter a "default" policy rule that will match anything and instruct the AA to supply the AFFILIATION = "Active Member of the Community" attribute. If there is a match, then the AA must:
- evaluate the Policy Expressions in the matching ruleset, to determine which attributes to return tot he SHAR,
- perform the mapping process, to map "Shibboleth standard attribute names" from step a into local site attribute names,
- contact the local Attribute Repository, and retrieve the required attributes for the user's local identity.
- perform an inverse mapping process, to convert the local attributes into "Shibboleth standard attribute names and values".
[Build an ARM]
[Return the ARM]
When evaluating the Policy Expressions in the matching ruleset, the AA may discover that the Policy Expressions specify that NO attributes should be return. In this case, the AA should construct an ARM with NO attributes, and return it to the SHAR. The AA shold NOT treat this situation as an error.
When evaluating the Policy Expressions in the matching ruleset, the AA may discover that the Policy Expressions require user interaction. In this case, the AA must [BLAH].
When the SHAR receives the ARM, it must [verify the AA speaker].
If the ARM indicates an error, [BLAH].
If the ARM indicates that user interaction is required, then [BLAH]. If the SHAR does not support this option,
If the ARM contains attributes, then the SHAR must perform the mapping process required to convert "Shibboleth standard attribute names and values" to local attribute names and values at the target.
SHAR caching....
5. Message Specifications
5.1 Attribute Query Handle Request (AQHR)
This message is used to request an Attribute Query Handle (AQH). It has the following format:
http://HandleServiceURL/?target=value&shire=value&ShibCmd=GetHandle
| field | value |
| HandleServiceURL | returned by the WAYF service |
| target | target destination URL originally requested by user (including all parameters, etc) |
| shire | FQDN of the SHIRE requesting the AQH (as determined by target) |
| ShibCmd | GetHandle (the verb indicating this command) |
Normally, messages are defined independently of the transport mechanism. At run time, they are bound to one of several different possible transport mechanisms. However, an AQHR can ONLY be sent via HTTP redirection. Consequently, message and transport are both defined here.
Message data is passed using the query string in the redirection URL (the part after the '?' character). Any parameter names and/or values passed must be URL-encoded in accordance with RFC 1738.
5.2 Attribute Query Handle Response (AQHR)
This message is used to return an AQHR. It has the following format:
http://target/?AQHR_ver=value&AQHR_handle=value&AQHR_shire=value&AQHR_ip=value&AQHR_time=value&AQHR_method=value1[,value2]&AQHR_aa=value&AQHR_sig=value
Note: ? is optional. It should be inserted only if it does not already appear in the url.
| field | value |
| target | value passed in AQHR |
| AQHR_ver | containing a major.minor version number |
| AQHR_handle | opaque user handle |
| AQHR_shire | FQDN of SHIRE as passed by target |
| AQHR_ip | IP address of browser process associated with handle |
| AQHR_time | AQHR issue time, in seconds since midnight 1/1/70 |
| AQHR_method | - comma-delimited list of AA
binding methods/types
- types are integers defined by Shibboleth spec - eg. 0=URI, 1=TCP(hostname:port), ... |
| AQHR_aa | - comma-delimited list of of
AA binding strings [SYNTAX?]
- semantic content depends on corresponding AQHR_method |
| AQHR_sig | - Shib signature of digest
- SHA1 digest is computed over the concatenation of the first six parameter values |
Normally, messages are defined independently of the transport mechanism. At run time, they are bound to one of several different possible transport mechanisms. However, an AQHR can ONLY be sent via HTTP redirection. Consequently, message and trasnport are both defined here.
5.3 Attribute Query Message (AQM)
(tbd)
5.4 Attribute Response Message (ARM)
(tbd)
Regarding who validates which aspects of the AASID and regulates its proper use, Bob likes Marlena's approach which maps the division as closely as possible to the client-cert case.
6. Bindings to Transport Protocols
8.1 HTTP
See, in the SSTC document repository,
Title : An HTTP Binding for SAML Messages
Author(s): Evan Prodromou
Filenames: draft-prodromou-http-binding-00.txt
Date : 15 May 2001
7. Implementing Trust Between Various Entities
The Shibboleth system provides a relying party with authorization-related attributes that are associated with a request for a web-based resource, in a way that meets a reasonable level of assurance in both the validity of the attributes and their being properly associated with the originator of the request.
7.1 Managing the Set of Trusted Speakers
A fundamental aspect of making a judgement about the validity of attributes and their utility in making access-control decisions is the identity of the asserter of the attributes, that is, who says that these things are true. So, a relying party needs a method of managing the set of identities that it is prepared to accept assertions from, and the system has to provide means of strongly associating assertions with those speakers.
7.2 Naming of attributes, supporting name constraints
A fundamental aspect of policy in this regard is constraining the nature of assertions that will be accepted from asserting parties. That is, permitting every party from whom assertions will be accepted to make any possible assertion is likely to pose an unacceptable level of risk for the relying party, and to severely limit the set of parties from whom it will accept assertions. So, a method of constraining the nature of assertions to limit this risk is important. (This is the role of the "name constraints" feature of X.509.)
Attribute names and values also must be named. As noted in section 1, it is useful to constrain acceptable attribute contents based on the identity of the attribute asserter. This implies conventions for naming some aspects of attributes.
It may be that attribute names come from a single agreed-upon space for all Shibboleth participants, hence constraints on attribute names are not needed.
The need for constraints, hence well-defined naming, on attribute values, probably varies by attribute. An obvious case is EPPN. A relying party may wish to constrain the values of EPPN based on the identity of the asserting party.
This design requires that by default SHARs have a policy that requires EPPN values to have a domain-part that matches the name of the asserting party. Thus, asserting parties would expect this constraint and would have to name themselves and their attributes to conform to it.
Example: by default, A SHAR will have policy to reject the assertion of the attribute-value "EPPN = gettes@georgetown.edu" in an assertion produced by "washington.edu".
This suggests that values of attributes expressing group membership also be associated with DNS domains, and be subject to the same constraint.
Some attribute values may be, in their native form, from a global name space. EduPersonAffiliation is an example. Its values are "faculty", "staff", "member", etc. The intent of these global names, however, is not to form a global group consisting of all members from all asserting parties, but rather to be interpreted as local to the asserting party.
Example: In an attribute assertion produced by "washington.edu", the value "member" for the attribute "eduPersonAffiliation" is correctly interpreted to mean "member of the washington.edu community".
Thus some attributes are inherently constrained by the names of the asserting parties.
8. Notes on Signing
The Handle Service, the Attribute Authority, and the SHAR are all required to sign elements.
Signing is done using a SSL server certificate. Therefore, the Domain Name of the "server" runing each service should correspond to the SubjectName of such a cert. If assertions are delivered via a SSL/TLS-protected protocol, the asserting party takes the server role and uses the same SSL server cert to authenticate itself.
signed with what algorithm?
base64-encoded RSA signature of SHA1 digest in PKCS#1 format as per XMLSignature section 6.4.2
9. Establishing the Identity of Speakers
This section describes conventions for naming of security components in the Shibboleth system, including a particular mapping to currently-deployed X.509-based public-key infrastructure.
1. Naming and name constraints
This section defines a naming scheme to help relying parties determine the name of the entity they are speaking with. The scheme is based on established DNS-based Internet naming and on existing X.509 PKI practice to provide a straightforward mapping to existing widely-used naming schemes.
It is worth noting that for the most part naming is a deployment-time decision. A particular protocol, and even a particular deployment, could potentially support many different naming schemes at the same time. But agreement on at least one scheme is necessary to provide interoperability among parties.
2. Principles
The design is based on these principles.
(P1) Usable naming should be based on DNS.
(P2) The only scheme currently in use supporting naming on an Internet scale, among multiple administrations, meeting some non-trivial level of assurance, is provision of X.509 SSL server certificates for use with SSL/TLS-based application protocols. The only elements of the names in these certificates that are used in the security protocols are the DNS host names in the subject field.
(P3) For information supplied by a source directly to a receiver, and only used by that receiver, it is equivalent to provide the information via (a) a SSL/TLS-protected protocol connection (eg HTTP) authenticated using a SSL server cert, or (b) putting it into a signed object (eg S/MIME) signed using the same cert.
Thus, this design suggests naming of entities using DNS names, and supporting secure information exchange using SSL-based protocols with DNS-based X.509 SSL server certificates.
3. Naming of speakers
The three kinds of speakers that must be named are Handle Services (which issue AQRs), attribute authorities (which process attribute requests and issue attribute assertions), and attribute requesters (aka SHARs). This design proposes naming these with DNS names.
The DNS name for the WAYF service will be a well known constant (derived from RSA's private key). The WAYF service returns a URL for the origin site's Handle Service. This URL will contain the host name for the server running the Handle Service. The Handle Service will return an AQHR. One attribute in the AQHR is AQHR_aa, which has as its value a comma-delimited list of of AA binding strings. Each of these will contain the host name for a server running an Attribute Authority.
[NEW - CHECK THIS PARAGRAPH] The standard situation is that each of these speakers should use an SSL server certificate with the DNS name of the organization in the subject field of the certificate.
Example: The Handle Service for the University of Washington would be named using its DNS domain, "washington.edu". If authentication assertions issued by the UW's Handle Service are signed (eg using S/MIME or XML DSIG), the signing is done using a SSL server certificate with the DNS name "washington.edu" in the subject field. If assertions are delivered via a SSL/TLS-protected protocol, the asserting party takes the server role and uses the same SSL server cert to authenticate itself.
Example: A SHAR for the target "http://encyclopedia.example.com/" would, acting as a client in an SSL-protected protocol exchange with an AA, authenticate itself with a SSL server certificate with the DNS name "encyclopedia.example.com" in the subject field.
It is possible, but limiting, to name the attribute authority for a user domain using the same name as the domain itself (eg "washington.edu" in the above example). A mapping to a different name could be established in the AQHR, eg by providing a URL for the AA which establishes its service name.
Example: An AQHR from "washington.edu" includes a field: "AA URL = https://shib-aa.washington.edu/". Attribute assertions from this AA would then use an SSL server certificate with this name in the subject field for authentication.
A SHAR, when processing authentication and attribute assertions, can check asserting-party DNS names against its local database of acceptable speakers to make judgements about whether to accept an assertion. This database would be keyed by DNS name.
Being able to accept X.509 SSL server certificates across domains, for the purposes described above, would depend on those certificates being issued by CAs that are acceptable to relying parties. It is already common practice in applications deployed by Internet2 members to rely on SSL server certificates issued by public CAs (eg VeriSign) and higher-ed CAs (eg CREN). Shibboleth would suggest a set of CAs to be relied on by its participants for this purpose.
10. Functionality Required in the AA Policy Language
The AA Policy Language must be able to express the minimum functionality required in Policy Expresions. Individual implementations are free to add value beyond the minimum specified here.
Policy Expressions consist of three components: a target specification, an action specification, and an attribute specification. A target specification consists of a SHAR and an optional target URL. An action specification is used to indicate what action the AA should take if an AQM request matches this Policy Expression. Allowable values might include: always release the attributes specified in the attribute expresion, never release anything, or "ask the user". An attribute specification is used to indicate which Shibboleth standard attribute names (and, optionally, which values) are to be released if an AQM request matches this Policy Expression.
11. The Attribute Authority - Directory Service API
12. Specification 1
The Shibboleth protocol supports a myriad of options. In order to ensure the interoperability of implementations, it is necessary to define a minimal configuration which must be supported by all implementations. This minimal configuration is subject to change as technology and requirements evolve. This section defines the first specification of these options. Implementations which are configured in this way can be said to support Shibboleth Version 1 Specification 1 (1.1).
Handle Server
- MUST support the get_Attribute_Query_Handle Message Exchange Sequence
- SHOULD/MAY support existing web ISO/SSO login mechanisms at the origin site.
Attribute Authority
- MUST support all of the functionality of the get_attributes Message Exchange Sequence EXCEPT for the two optional messages
- MAY support the two optional messages
- MUST suport "3.3.1.1 Attribute Release Policy Management". An implementaiton must provide a way of doing this; however, the design and functionality are leftto the implementors.
- MAP support "3.3.1.2 Real-time Control of Attribute Release".
- SHOULD support the DELETE USER function of "3.3.1.3 Life-cycle Maintenance of Users".
- MUST support the HTTP transport defined in "Bindings to Transport Protocols".
- MUST support entering site policies that apply to all users.
- MUST support entering user specific policies that apply to a single user.
- The Policy Language MUST support the following features:
- ???
- MUST support [BLAH] re attribute mapping
- The Attribute Authority MUST be able to encode and send the following attributes:
- eduPersonPrincipalName
- eduPersonAffiliation
- eduPersonExtGroupMembership
- The Attribute Authority MAY support additional attributes.
- attribute mapping?
SHIRE
- The SHIRE SHOULD maintain session state.
SHAR
- MUST support sessions at the target.
- Scope of Assertions - Each origin domain can only issue assertions about users and groups within its domain. It cannot issue assertions about entities based in other domains. For instance, washington.edu can iisue an attribute assertion about rlmorgan@washington.edu, but cannot issue any attribute assertions about gettes@georgetown.edu.
WAYF
- ???
Trust
- how establish the set of trusted speakers?
- MUST establish the identity of trusted speakers as described in "9. Establishing the Identity of Speakers".
Assertions
- Complete list of V1.0 SHAR/AA attributes:
- eduPersonPrincipalName
- eduPersonAffiliation
- eduPersonExtGroupMembership
- eduPersonEligibility
Signing
- ???
Atribute Authority - Attribute Repository API
- ???
13. Constants and Other Defined Values
13.1 Attribute Authority Binding Methods/Types
eg. 0=URI, 1=TCP(hostname:port)
13.2 Constants
- AQHR_ver
- "1.0" the current major.minor version number
13.3 Shibboleth standard attribute names and values
14. References
[bradner97] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Westerinen00] A. Westerinen, et al., "Policy Terminology, INTERNET-DRAFT, November 24, 2000.
[Hazelton00] Hazelton, Keith, et al. eduPerson 1.0 Schema, January 2001.
[de Laat00] de Laat, C., et al. "Generic AAA Architecture", RFC 2903, August 2000.
15. Acknowledgements
The authors gratefully acknowledge the suggestions of the members of the mace-shibboleth list.
In addition, this document has drawn heavily from a number of individual submissions to the shibboleth project.