Page tree
Skip to end of metadata
Go to start of metadata

Out of date, needs revision.

Installation Directory

The IdP installation/home directory will contain the following directories:

  • bin - contain the various shell scripts for starting/stoping the IdP and running command line tools that come with it
  • bin/lib  - libraries needed only by command line tools
  • conf - IdP's configuration files
  • credentials - credentials used by the IdP (e.g., browser-facing cert/key, signing/encryption key/cert, metadata validation certs)
  • jetty - the Jetty Servlet container
  • logs - IdP's log files
  • metadata - local (cached) metadata files
  • templates - Velocity templates used to render the UI
  • war - expanded WAR file (command line tools will include the WAR's lib directory in their classpath)
  • webflows - Spring webflow definitions used to specify protocol and authentication request handling
The IdP upgrade script will delete and replace the bin, bin/lib, jetty, and war directories.  Deployers must not make changes to these directories or they will be lost during upgrades.

Configuration Files

The following configuration files will reside in the conf directory:

attribute-filter.xml

Same purpose as in IdPv2.

attribute-resolver.xml

Same purpose as in IdPv2.

installer.properties

Properties written out by the installer and used during upgrades. Scripts may create this ahead of time and feed it in to the installer in order to have a silent install. Deployers are not expected to modify this directly.

internal.xml

Same purpose as in IdPv2. The session timeout configuration will no longer be in here.

idp.properties

A set of name/value pairs that are used to replace macros within the XML configuration files. See below.

jetty.xml

Jetty's configuration file. In general deployers are not expected to modify this but may do so if they wish to enable certain advanced Jetty features.

metadata.xml

Used to define the metadata providers for the IdP (this used to be the relying-party.xml file in IdPv3). To simplify the configuration, this file will:

  • remove the need for chaining metadata providers and filters
  • contain a pre-defined metadata provide for locally maintained metadata (it will simply point to a file containing an empty <EntitiesDescriptor> initially)
  • contains a pref-defined "federation" metadata provider that reads the URL, validity period, and cert path from the idp.properties file.

See example config file >>

relying-party.xml

Same purpose as in IdPv2 sans all metadata, credential, trust engine, and security policy definitions. To simplify configurations, this file will:

  • assume all communication profiles are enabled (any profile can be explicitly disabled if need be) - all profiles will still be off for the anonymous relying party configuration
  • individual configuration files will have all settings defaulted so that only those options that need to be changed need to be declared
  • security configuration will be defaulted (and thus need not be declared) but can be changed explicitly

See example config file >>

security.xml

Security related configuration including: credentials and trust engines (these were in relying-party.xml in IdPv2), clock skew, white/blacklisted crypt algorithms.

See example config file >>

Property File Based "Lite" Configuration

A review of many existing deployments suggests that most use LDAP for user authentication and attributes and pull in metadata from a single source, via HTTP, and check that metadata via its signature.  Therefore, this proposal pulls out all of the configuration options associated with those items and replaces them with macros in the default configuration file.  When the files are loaded the values for the macros are read from a property file. This allows deployers, deploying in a particular common environment, to configuration a fair amount of their IdP by simply adjusting a properties file.

The "Lite" configuration would assume LDAP authentication and attribute data source and metadata pulled from a URL. That in turn would lead to the following properties needing to be filled in:

  • metadata URL
  • metadata trust cert optional
  • LDAP URL (hostname, port, base DB)
  • LDAP credentials (principal DN and password) optional

So, for example, an attribute resolver data connector configured this way would look like this (assuming a particular format for the macros):

 

<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
 
        <FilterTemplate>
            <![CDATA[
                (uid=$requestContext.principalName)
            ]]>
        </FilterTemplate>
 
    </resolver:DataConnector>

 

It is probably true that for 90%+ of the sites all they would ever touch is the properties file and the attribute-filter file, assuming this is coupled with the previous proposal.

  • No labels