From 1bb9733b83bf63c184ea75efcfd7650b0325bfa9 Mon Sep 17 00:00:00 2001 From: ndk Date: Fri, 16 Apr 2004 21:22:03 +0000 Subject: [PATCH] Corrects an inaccuracy in the mechanics of ARP specification. git-svn-id: https://subversion.switch.ch/svn/shibboleth/java-idp/trunk@990 ab3bd59b-922f-494d-bb5f-6f0a3c29deca --- doc/DEPLOY-GUIDE-ORIGIN.html | 486 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 401 insertions(+), 85 deletions(-) diff --git a/doc/DEPLOY-GUIDE-ORIGIN.html b/doc/DEPLOY-GUIDE-ORIGIN.html index a8964a0..c26a784 100644 --- a/doc/DEPLOY-GUIDE-ORIGIN.html +++ b/doc/DEPLOY-GUIDE-ORIGIN.html @@ -139,8 +139,14 @@ April 14, 2004

This version of the deploy guide is for Shibboleth v1.2. For documentation related to prior versions of Shibboleth, please consult the appropriate branch in the Shibboleth CVS.

-

The default configuration of Shibboleth is not secure and should not be used for protection of production content. The example private key bundled with the distribution is publically available, widely circulated, and well-known; also, the default federation -and trust metadata is for testing purposes only. For information about securing a Shibboleth deployment, please refer to the production guide. Shibboleth should only be used to protect sensitive content when deployed carefully in conjunction with proper trust settings and policies.

+

The default configuration of Shibboleth is not secure and should not +be used for protection of production content. The example private key bundled +with the distribution is publically available, widely circulated, and +well-known; also, the default federation and trust metadata is for testing +purposes only. For information about securing a Shibboleth deployment, please +refer to the production guide. Shibboleth should only be used to protect +sensitive content when deployed carefully in conjunction with proper trust +settings and policies.

Insert features here.

@@ -172,6 +178,8 @@ that arises. Please ensure that you have the
  • Target
  • WAYF
  • Federations
    • +
  • Relying Parties and Applications
    • +
  • Sessions
  • @@ -367,13 +375,70 @@ requesting attributes.

    information on local authentication and authorization practices for federation members.

    -


    -
    -
    -

    +

    1.e. Relying Parties and Applications

    +
    +

    A Shibboleth relying party represents a target or set of targets that + operate under one trust agreement and share common key, certificate, and + certificate authority guidelines. This could include any number of + individual SHAR's and applications. Frequently, an entire federation will + be viewed by an origin or target as a single relying party; however, there + is no necessary binding between these. An individual site with which an + origin or target exchanges information may sometimes be part of multiple + relying parties if there are multiple trust agreements under which these + transactions are performed.

    +

    Applications as viewed from Shibboleth are not necessarily defined by the + same metrics as in other contexts. An individual application represents a + service or set of services that operates using the same attribute and trust + features and shares common Shibboleth sessions. + Attributes are released to targets on the basis of individual applications + within the context of its containing relying party. An application may span + multiple URL trees, servers, or SHAR's, depending on the architecture of the + service. However, every application must be contained within a single + relying party; applications cannot span relying parties. Each application + is assigned an individual application identifier URN which must be + recognized by both the origin and the target.

    +
    +

    1.f. Sessions

    +
    +

    There are many different types of sessions that can be established within + the context of the access of a Shibboleth-protected resource. It is + important to note that these are all independent and distinct: any session + can exist with or without any other session, and the expiration of any one + session does not imply the expiration of any other session. Shibboleth does + not support any logout functionality.

    +

    The successful access of a Shibboleth-protected resource by a browser + user may have two outcomes. The standard session establishment mechanism in + which Shibboleth protects the resource in all circumstances results in the + establishment of two sessions. Shibboleth 1.2 also supports so-called lazy + session establishment, in which the resource may be accessed without first + providing a home institution or obtaining attributes. This means the + application must be intelligent enough to determine whether an attribute + request or any other aspect of Shibboleth functionality is necessary, and + then construct proper URL's to initiate these flows; if the application + determines none is necessary or uses other authorization mechanisms, then an + attribute request does not need to be triggered. This complex functionality + is mostly useful to protect a single URL with different access mechanisms, + or to require attribute requests only in the instance where the application + deems it necessary.

    +

    In either situation, before the resource is presented, a Shibboleth + session is established between the browser and the Shibboleth module, + represented by a cookie. A separate session for the attribute release + interaction with the origin results in the caching of a set of attributes + pertaining to that browser user. The expiration of either session implies + the need to re-initiate only that session and does not imply the + re-initiation of the other; for example, although a browser user's + Shibboleth session has expired, if there is a valid set of cached + attributes, there need not be another attribute query when they next access + this resource.

    +

    Independently of this, a web-based application protected by Shibboleth + may have a need to establish its own session with the user. This session + may persist well beyond either Shibboleth session, and logouts from this + session, if supported, will not terminate Shibboleth sessions initiated to + access the resource. Application administrators should carefully evaluate + the expiration of all sessions to limit vulnerability to attacks or user + negligence.

    +
    -


    -

    2. Planning

    There are several essential elements that must be present in the environment to ensure Shibboleth functions well, both political and technical. Shibboleth is @@ -678,7 +743,10 @@ and JSP specification 1.2.

    $TOMCAT_HOME/webapps/shibboleth/WEB-INF/classes/. To specify files outside of the webapp, specify a full URI, such as file:///usr/local/shibboleth/.

    -

    The following is a hyperlinked version of the basic configuration file, followed by a list of elements and attributes that must be modified. Click on any attribute or element for more information on its population and definition.

    +

    The following is a hyperlinked version of the basic configuration file, + followed by a list of elements and attributes that must be modified. Click + on any attribute or element for more information on its population and + definition.

    <?xml version="1.0"encoding="UTF-8"?>
    @@ -735,7 +803,8 @@ and JSP specification 1.2.

    </ShibbolethOriginConfig>
    -

    The following changes must be made to the default configuration before the origin will interoperate in a federation.

    +

    The following changes must be made to the default configuration before the +origin will interoperate in a federation.

    1. Attributes within the JSP specification 1.2.

    2. providerID=URN
      -

      This will be the URN assigned to this origin by the federation.

      +

      This will be the URN assigned to this origin by the + federation.

    3. defaultRelyingParty=URN
      -

      This is the URN of the primary federation that the origin operates within.

      +

      This is the URN of the primary federation that the origin + operates within.

  • -

    Although not explicitly necessary, it's highly recommended for initial installation and testing that logging be activated at the DEBUG level by uncommenting the second Logging element and ensuring that the pathnames for TransactionLog and ErrorLog are appropriate. However, in production, this will slow the operation of the origin considerably.

    +

    Although not explicitly necessary, it's highly recommended for + initial installation and testing that logging be activated at the DEBUG level by uncommenting the second Logging element and + ensuring that the pathnames for TransactionLog and ErrorLog are + appropriate. However, in production, this will slow the operation of + the origin considerably.

  • -

    The default configuration file informs Shibboleth to load its key and certificate from flat files. The Key element specifies a key in DER format located at /conf/shib2.key, while the Certificate element specifies the corresponding certificate in PEM format located at /conf/shib2.crt. If any of these values is inconsistent with your deployment, change it accordingly. Note that keys are supported in a variety of formats: DER, PEM, encrypted PEM, PKCS8, and encrypted PKCS8. If a keystore must be used instead, consult section 5.a for appropriate structure and details on population.

    -

    To create proper keys and certificates for production use, please refer to section 4.b.

    +

    The default configuration file informs Shibboleth to load its key and + certificate from flat files. The Key element specifies a key in DER format located at /conf/shib2.key, while the Certificate + element specifies the corresponding certificate in PEM format located at /conf/shib2.crt. If any of these values is + inconsistent with your deployment, change it accordingly. Note that + keys are supported in a variety of formats: DER, PEM, encrypted PEM, + PKCS8, and encrypted PKCS8. If a keystore must be used instead, consult + section 5.a for appropriate structure and details on + population.

    +

    To create proper keys and certificates for production use, please + refer to section 4.b.

    • @@ -814,10 +907,11 @@ configuration process.

    The following text suggests a way to generate a key and certificate in - flat-file PEM format, which will be simplest for most deployments. On Unix, - OpenSSL must be installed to perform this process. On Windows, OpenSSL - libraries and the command line tool are included in the package and can be - used directly, if not otherwise available.

    + flat-file PEM format, which will be simplest for most deployments. Once the + key pair is generated, the public key must be sent to a certificate + authority recognized by relying parties with which this origin will interact + to be signed into a certificate. OpenSSL must be installed to perform this + process.

    The certificate and key file location should be based on whether they will also be used for Apache. If they will be used as a server certificate @@ -942,8 +1036,22 @@ configuration

    5. Advanced Configuration

    5.a. origin.xml

    -

    Shibboleth 1.2 origins are configured using the origin.xml file located in - /webapps/shibboleth/WEB-INF/classes/conf/origin.xml. The XML consists of a set of individual elements that describe how the origin should operate, which may each have their own attributes or appear within other elements. This structure is represented through cross-references in the definitions and the examples presented in section 4.a, below, and through the examples in CVS. The following is an example origin.xml file which contains all possible configuration parameters and values. The configuration must be consistent with values elsewhere in the deployment or access errors may occur. For a more basic example, consult section 4.a. This is useful to demonstrate the structure that other types of configurations have. Few deployments will need configuration files this complex.

    +

    Shibboleth 1.2 origins are configured using the origin.xml file located in /webapps/shibboleth/WEB-INF/classes/conf/origin.xml. + The XML consists of a set of individual elements that describe how the + origin should operate, which may each have their own attributes or appear + within other elements. This structure is represented through + cross-references in the definitions and the examples presented in section 4.a, below, and through the examples + in CVS. The following is an example origin.xml file which contains all possible + configuration parameters and values. The configuration must be consistent + with values elsewhere in the deployment or access errors may occur. For a + more basic example, consult section 4.a. This is useful + to demonstrate the structure that other types of configurations have. Few + deployments will need configuration files this complex.

    <?xml version="1.0" encoding="UTF-8"?>
    @@ -1024,13 +1132,18 @@ configuration </ShibbolethOriginConfig>
    -

    The following is a complete, alphabetical list of all configuration elements and their valid attributes and population. Each element also has a description of the elements it may contain and the elements that may contain it.

    +

    The following is a complete, alphabetical list of all configuration + elements and their valid attributes and population. Each element also has a + description of the elements it may contain and the elements that may contain + it.

    -

    All pathnames are relative, and have an effective root path of - $TOMCAT_HOME/webapps/shibboleth/WEB-INF/classes/. - To specify files outside of the webapp, specify a full URI, such as - file:///usr/local/shibboleth/.

    -

    All elements are optional unless otherwise specified. All attributes of an element are optional unless designated mandatory by a purple background.

    +

    All pathnames are relative, and have an effective root path of $TOMCAT_HOME/webapps/shibboleth/WEB-INF/classes/. To + specify files outside of the webapp, specify a full URI, such as file:///usr/local/shibboleth/.

    +

    All elements are optional unless otherwise specified. All attributes of + an element are optional unless designated mandatory by a purple background.

    <ArpRepository implementation ="edu.internet2.middleware.shibboleth.aa.arp.provider.FileSystemArpRepository">
    @@ -1111,70 +1224,182 @@ configuration class="fixed">Logging element.
    <confFederationProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadataLoadWrapper" uri="pathname"/>
    -
    Individual sets of targets in the form of a sites.xml file that this origin will trust to make requests may be specified by adding FederationProvider elements to the main ShibbolethOriginConfig element for each. The URI points to a sites.xml file, which is generally distributed by federations.
    +
    Individual sets of targets in the form of a sites.xml file that this origin will trust to make + requests may be specified by adding FederationProvider elements to the main ShibbolethOriginConfig element for each. The + URI points to a sites.xml file, which is generally distributed by + federations.
    <FileResolver Id="string">
    -
    This element defines a pair of files used to store a private key and certificate associated with a given identifier and is contained by the Credentials element. RelyingParty elements will refer to these identifiers allowing multiple resolver elements to be used to specify different credential storage for different federations or target sites. It must contain one Key element and should contain one Certificate element.
    +
    This element defines a pair of files used to store a + private key and certificate associated with a given identifier and is + contained by the Credentials element. RelyingParty + elements will refer to these identifiers allowing multiple resolver + elements to be used to specify different credential storage for + different federations or target sites. It must contain one Key element and should + contain one Certificate element.
    <HSNameFormat nameMapping="id"/>
    -
    Individual RelyingParty elements may contain this element to specify the NameMapping element referenced by id to be used in generating subject names for this relying party. If this element is not present, default Shibboleth handles will be used.
    +
    Individual RelyingParty elements may contain this element + to specify the NameMapping element referenced by id to be used in generating subject names for this + relying party. If this element is not present, default Shibboleth + handles will be used.
    <Key format="type">
    -
    This specifies the file containing a private key to be used by a set of credentials. Valid encodings are PEM and DER. Keys are supported in a variety of formats: DER, PEM, encrypted PEM, PKCS8, and encrypted PKCS8. It resides within the FileResolver element, should be paired with a Certificate element, and contain a Path element.
    +
    This specifies the file containing a private key to be + used by a set of credentials. Valid encodings are PEM and DER. Keys are + supported in a variety of formats: DER, PEM, encrypted PEM, PKCS8, and + encrypted PKCS8. It resides within the FileResolver + element, should be paired with a Certificate element, and contain a Path element.
    <KeyAlias>string</KeyAlias>
    -
    Specifies the alias used for accessing the private - key. Contained by the KeyStoreResolver element.
    +
    Specifies the alias used for accessing the private + key. Contained by the KeyStoreResolver element.
    <KeyPassword>string</KeyPassword>
    -
    Specifies the password used to retrieve the private - key. Contained by the KeyStoreResolver element.
    +
    Specifies the password used to retrieve the private + key. Contained by the KeyStoreResolver element.
    <KeyStoreKeyAlias>string</KeyStoreKeyAlias>
    -
    Specifies the alias used for accessing the private - key. Contained by the NameMapping element when a CryptoHandleGenerator type is specified.
    +
    Specifies the alias used for accessing the private + key. Contained by the NameMapping element when a CryptoHandleGenerator type is specified.
    <KeyStoreKeyPassword>string</KeyStoreKeyPassword>
    -
    Specifies the password used to retrieve the private - key. Contained by the NameMapping element when a CryptoHandleGenerator type is specified.
    +
    Specifies the password used to retrieve the private + key. Contained by the NameMapping element when a CryptoHandleGenerator type is specified.
    <KeyStorePassword>string</KeyStorePassword>
    -
    Specifies the password to access the keystore containing the private key to be used for symmetric encryption. Contained by the NameMapping element when a CryptoHandleGenerator type is specified.
    +
    Specifies the password to access the keystore + containing the private key to be used for symmetric encryption. + Contained by the NameMapping element when a CryptoHandleGenerator type is specified.
    <KeyStorePath>string</KeyStorePath>
    -
    Specifies the location of the keystore containing the private key to be used for symmetric encryption to pass handles between the HS and AA. Contained by the NameMapping element when a CryptoHandleGenerator type is specified.
    +
    Specifies the location of the keystore containing the + private key to be used for symmetric encryption to pass handles between + the HS and AA. Contained by the NameMapping element when a CryptoHandleGenerator type is specified.
    <KeyStoreResolver Id="string" storeType="type">
    -
    This element is contained by the Credentials element and to specify a keystore that contains both the certificate and private key for a given set of credentials. Typically, this will be a Java keystore, with a corresponding type of JKS. RelyingParty elements will refer to the Id allowing multiple resolver elements to be used to specify different credential storage for different federations or target sites. It must contain one Path element, one KeyAlias element, and one StorePassword element; it may optionally contain a KeyPassword element or a CertAlias element.
    +
    This element is contained by the Credentials + element and to specify a keystore that contains both the certificate and + private key for a given set of credentials. Typically, this will be a + Java keystore, with a corresponding type of JKS. RelyingParty elements will refer to the Id allowing multiple resolver elements to be used + to specify different credential storage for different federations or + target sites. It must contain one Path element, one KeyAlias element, and one StorePassword + element; it may optionally contain a KeyPassword element or a CertAlias + element.
    <Log4JConfig location="pathname"/>
    -
    This element informs Shibboleth to utilize Log4J as a logging system and points to the relevant configuration file using the location attribute. A basic configuration is included with the distribution at /WEB-INF/classes/conf/log4j.properties. This is set up to log to the console of the servlet container with a level of WARN, but there is also a commented-out example in the file to give a possible alternate configuration. This element must be contained by a Logging element and may not be paired with a TransactionLog or ErrorLog element.
    +
    This element informs Shibboleth to utilize Log4J as a + logging system and points to the relevant configuration file using the + location attribute. A basic configuration is + included with the distribution at /WEB-INF/classes/conf/log4j.properties. This is + set up to log to the console of the servlet container with a level of + WARN, but there is also a commented-out example in the file to give a + possible alternate configuration. This element must be contained by a + Logging element + and may not be paired with a TransactionLog or ErrorLog element.
    <Logging>
    -
    This container element identifies a logging method for both the HS and AA to use and may not occur more than once. Three different logging methods may be specified depending on what is placed inside this element. If nothing is specified, then all logs go to the container console. If ErrorLog and TransactionLog elements are present, more traditional logging flatfiles will be generated at the locations specified. A Log4JConfig element instructs the origin to use Log4J logging.
    +
    This container element identifies a logging method for + both the HS and AA to use and may not occur more than once. Three + different logging methods may be specified depending on what is placed + inside this element. If nothing is specified, then all logs go to the + container console. If ErrorLog and TransactionLog + elements are present, more traditional logging flatfiles will be + generated at the locations specified. A Log4JConfig + element instructs the origin to use Log4J logging.
    <NameMapping xmlns="urn:mace:shibboleth:namemapper:1.0"
    format="URN"
    handleTTL="seconds"
    id="string"
    type="type"/>
    -
    This element defines a name mapping system to create SAML assertion subject names for users; in standard Shibboleth, this will be the creation of a handle to be given to the SHAR and shared with the AA. +
    This element defines a name mapping system to create + SAML assertion subject names for users; in standard Shibboleth, this + will be the creation of a handle to be given to the SHAR and shared with + the AA.
    <Path>pathname</Path>
    -
    This mandatory element specifies the path to a file or directory utilized by other elements of the configuration. It may be contained by various elements to point to different types of files required by the origin.
    +
    This mandatory element specifies the path to a file or + directory utilized by other elements of the configuration. It may be + contained by various elements to point to different types of files + required by the origin.
    <ReleasePolicyEngine>
    -
    The ReleasePolicyEngine element is used to specify a class of release policy processing and enforcement and is not mandatory, defaulting to ???. This should contain one ArpRepository element.
    +
    The ReleasePolicyEngine + element is used to specify a class of release policy processing. This + should contain one ArpRepository element.
    <RelyingParty name="URN"
    AAsigningCredential="string"
    @@ -1187,28 +1412,115 @@ signAttrResponses="true/false"
    signAuthAssertions="true/false"
    signAuthResponses="true/false"
    signingCredential="string">
    -

    The RelyingParty element is used to specify one or more relying parties that this origin must recognize. This includes any federations the origin is a member of, any targets that have established bilateral agreements with the origin, or any other trust structure that origin must be aware of. In addition to its attributes, this element may contain a HSNameMapping element to specify a naming mechanism for assertions sent to this relying party. The HS and AA both perform validation against federation metadata to ensure that targets cannot construct requests that cause another target's relying party information to be used.

    -

    The proper RelyingParty element to handle a given attribute request is selected by the following algorithm. If at any point a match is found, processing is complete; only one relying party will be used for any given request.

    -
      -
    1. If the requesting provider is unauthenticated -- due to a lack of SSL client authentication because the AA is not protected by an https:// URL -- the default relying party is always used.
      2. -
    2. If the requesting provider is Shibboleth 1.1 or less, the default relying party is used.
      3. -
    3. If a RelyingParty element's providerId attribute matches the name sent by the target, then that element is used.
      4. -
    4. A metadata lookup is performed using the sites.xml files supplied by FederationProvider elements to determine whether the target is a member of a common federation. If there is a RelyingParty element that has the same providerId as the URN of the the federation, it is used. If not, the default relying party handles the request.
      5. -
    -
      -
    • name: Each RelyingParty element is differentiated by a URN specified in the name attribute. A target will send a value for this attribute with the attribute request; if the URN sent matches the name, this element will be used in the transaction. If there is no direct match, the origin uses metadata to try to find a federation that the service provider is a member of.
      • -
    • AAsigningCredential: This attribute must equal the identifier of one of the FileResolver Id's. A separate set of credentials may be specified for the AA's signing of assertions/SSL session identification using this attribute, as opposed to the HS' signing of assertions. If this is not specified for this RelyingParty element, but a signingCredential attribute is, that set of credentials will be used instead. Ensure that the appropriate signing key is selected for each; an incorrect signing key will lead to trust failures.
      • -
    • AAUrl: Different AA's may be specified for different relying parties using this attribute. It over-rides, is populated, and operates in the same manner as the AAUrl attribute of the ShibbolethOriginConfig element.
      • -
    • defaultAuthMethod: The value of this attribute represents the mechanism by which the user's authentication was performed. It is used to populate authenticationMethod in SAML assertions passed to this relying party if no other authentication method is passed to the HS. For a brief list of authentication methods, consult the same attribute as part of the ShibbolethOriginConfig element.
      • -
    • passThruErrors: This boolean attribute determines whether the origin will relay errors in flows to this target for use in displaying these errors to the browser in the case of an unsuccessful transaction.
      • -
    • providerId: If the origin must assert under a different name to this relying party, specify a providerId attribute which will over-ride the one specified in ShibbolethOriginConfig.
      • -
    • signAttrAssertions: If this boolean attribute has a value of true, the attribute assertion within the SAML response will be signed. This is mostly useful for using the attribute assertion in contexts outside of the response and defaults to false.
      • -
    • signAttrResponses: If this boolean attribute has a value of true, the attribute response itself will be signed in addition to the security and authentication provided by the SSL session. SAML responses contain one or more assertions. Defaults to false; if true, an https:// AAUrl may be redundant.
      • -
    • signAuthAssertions: If this boolean attribute has a value of true, the authentication assertion within the SAML response will be signed. This is mostly useful for using the authentication assertion in contexts outside of the response and defaults to false.
      • -
    • signAuthResponses: If this boolean attribute has a value of false, the authentication response will not be signed. SAML responses contain one or more assertions. Defaults to true.
      • -
    • signingCredential: This attribute must equal the identifier of one of the FileResolver Id's. This allows the origin to use different signing keys and certificates for exchanges with different federations or targets. Ensure that the appropriate signing key is selected for each; an incorrect signing key will lead to trust failures.
      • -
    -
    +

    The RelyingParty element + is used to specify one or more relying parties that this origin must + recognize. This includes any federations the origin is a member of, any + targets that have established bilateral agreements with the origin, or + any other trust structure that origin must be aware of. In addition to + its attributes, this element may contain a HSNameMapping + element to specify a naming mechanism for assertions sent to this + relying party. The HS and AA both perform validation against federation + metadata to ensure that targets cannot construct requests that cause + another target's relying party information to be used.

    +

    The proper RelyingParty element to handle + a given attribute request is selected by the following algorithm. If at + any point a match is found, processing is complete; only one relying + party will be used for any given request.

    +
      +
    1. If the requesting provider is unauthenticated -- due to a lack of + SSL client authentication because the AA is not protected by an https:// URL -- the default relying party is + always used.
      2. +
    2. If the requesting provider is Shibboleth 1.1 or less, the default + relying party is used.
      3. +
    3. If a RelyingParty element's providerId attribute matches the name sent by the + target, then that element is used.
      4. +
    4. A metadata lookup is performed using the sites.xml files supplied by FederationProvider elements to determine + whether the target is a member of a common federation. If there is a + RelyingParty element that has the same + providerId as the URN of the the federation, it is used. If not, the + default relying party handles the request.
      5. +
    +
      +
    • name: Each RelyingParty element is differentiated by a URN + specified in the name attribute. A target + will send a value for this attribute with the attribute request; if + the URN sent matches the name, this element + will be used in the transaction. If there is no direct match, the + origin uses metadata to try to find a federation that the service + provider is a member of.
      • +
    • AAsigningCredential: This attribute + must equal the identifier of one of the FileResolver + Id's. A separate set of credentials may be specified for the AA's + signing of assertions/SSL session identification using this attribute, + as opposed to the HS' signing of assertions. If this is not specified + for this RelyingParty element, but a signingCredential attribute is, that set of + credentials will be used instead. Ensure that the appropriate signing + key is selected for each; an incorrect signing key will lead to trust + failures.
      • +
    • AAUrl: Different AA's may be specified + for different relying parties using this attribute. It over-rides, is + populated, and operates in the same manner as the AAUrl attribute of the ShibbolethOriginConfig element.
      • +
    • defaultAuthMethod: The value of this + attribute represents the mechanism by which the user's authentication + was performed. It is used to populate authenticationMethod in SAML assertions passed to + this relying party if no other authentication method is passed to the + HS. For a brief list of authentication methods, consult the same + attribute as part of the ShibbolethOriginConfig element.
      • +
    • passThruErrors: This boolean attribute + determines whether the origin will relay errors in flows to this + target for use in displaying these errors to the browser in the case + of an unsuccessful transaction.
      • +
    • providerId: If the origin must assert + under a different name to this relying party, specify a providerId attribute which will over-ride the one + specified in ShibbolethOriginConfig.
      • +
    • signAttrAssertions: If this boolean + attribute has a value of true, the + attribute assertion within the SAML response will be signed. This is + mostly useful for using the attribute assertion in contexts outside of + the response and defaults to false.
      • +
    • signAttrResponses: If this boolean + attribute has a value of true, the + attribute response itself will be signed in addition to the security + and authentication provided by the SSL session. SAML responses + contain one or more assertions. Defaults to false; if true, an https:// AAUrl may be redundant.
      • +
    • signAuthAssertions: If this boolean + attribute has a value of true, the + authentication assertion within the SAML response will be signed. + This is mostly useful for using the authentication assertion in + contexts outside of the response and defaults to false.
      • +
    • signAuthResponses: If this boolean + attribute has a value of false, the + authentication response will not be signed. SAML responses contain + one or more assertions. Defaults to true.
      • +
    • signingCredential: This attribute must + equal the identifier of one of the FileResolver Id's. This allows the origin to + use different signing keys and certificates for exchanges with + different federations or targets. Ensure that the appropriate signing + key is selected for each; an incorrect signing key will lead to trust + failures.
      • +
    +
    <ShibbolethOriginConfig
    xmlns="urn:mace:shibboleth:origin:1.0"
    @@ -1284,15 +1596,19 @@ resolverConfig="pathname">
    arp.user.$PRINCIPALNAME.xml. Up to two ARP's will apply to a principal: the site ARP, and the user ARP for that principal.

    -

    Each ARP acts as a container that holds a set of ARP rules that are - applicable to the principals that ARP is effective for. Each ARP rule - specifies a single release policy within the ARP container pertaining to a - specific set of targets, known collectively as a relying party. For 1.2 targets, this is a single URI matching a providerId attribute as defined in a RelyingParty element. Prior to 1.2, URI's for targets were not registered; this means that the SHAR name must be used in release policies for 1.1 targets accessed by users from this origin. Each ARP rule may contain specifications regarding the - release of any number of attribute values to requests matching that ARP rule - for that user. ARP rules may be flagged as default, implying that they are - always applied to any user matched by the ARP container. Note that ARP's may - also be used to restrict specific attribute/value pairs in addition to - restricting or releasing individual attributes.

    +

    Each ARP acts as a container that holds a set of ARP rules that are + applicable to the principals that ARP is effective for. Each ARP rule + specifies a single release policy within the ARP container pertaining to a + particular target application. For 1.2 targets, this is a single URI + matching a providerId. Prior to 1.2, URI's for + targets were not registered; this means that the SHAR name must be used in + release policies for 1.1 targets accessed by users from this origin. Each + ARP rule may contain specifications regarding the release of any number of + attribute values to requests matching that ARP rule for that user. ARP rules + may be flagged as default, implying that they are always applied to any user + matched by the ARP container. Note that ARP's may also be used to + restrict specific attribute/value pairs in addition to restricting or + releasing individual attributes.

    When a query is received, the AA generates an effective ARP, which is the fully evaluated set of ARP rules regarding that relying party based on all ARP containers applicable to the principal. This effective ARP is then applied -- 1.7.10.4