If the server is an IdP and/or an AA then there might be reasons to do things differently depending on who is asking; this is where that is specified. The keys are ‘default’ and SP entity identifiers. Default is used whenever there is no entry for a specific SP. The reasoning is also that if there is no default and only SP entity identifiers as keys, then the server will only except connections from the specified SPs. An example might be:

"service": {
    "idp": {
        "policy": {
            "default": {
                "lifetime": {"minutes":15},
                "attribute_restrictions": None, # means all I have
                "name_form": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            },
            "urn:mace:example.com:saml:roland:sp": {
                "lifetime": {"minutes": 5},
                "attribute_restrictions":{
                    "givenName": None,
                    "surName": None,
                }
            }
        }
    }
}

lifetime

This is the maximum amount of time before the information should be regarded as stale. In an Assertion this is represented in the NotOnOrAfter attribute.

attribute_restrictions

By default there is no restrictions as to which attributes should be return. Instead all the attributes and values that are gathered by the database backends will be returned if nothing else is stated. In the example above the SP with the entity identifier “urn:mace:umu.se:saml:roland:sp” has an attribute restriction: only the attributes ‘givenName’ and ‘surName’ are to be returned. There is no limitations as to what values on these attributes that can be returned.

name_form

Which name-form that should be used when sending assertions. Using this information the attribute name in the data source will be mapped to the friendly name, and the saml attribute name will be taken from the uri/oid defined in the attribute map.

If restrictions on values are deemed necessary those are represented by regular expressions.:

"service": {
    "aa": {
        "policy": {
            "urn:mace:umu.se:saml:roland:sp": {
                "lifetime": {"minutes": 5},
                "attribute_restrictions":{
                     "mail": [".*\.umu\.se$"],
                }
            }
        }
    }
}

Here only mail addresses that end with ”.umu.se” will be returned.

Indicates if the Authentication Requests sent by this SP should be signed by default. This can be overriden by application code for a specific call.

This sets the AuthnRequestsSigned attribute of the SPSSODescriptor node of the metadata so the IdP will know this SP preference.

Valid values are “true” or “false”. Default value is “false”.

Example:

"service": {
    "sp": {
        "authn_requests_signed": "true",
    }
}

Defines the set of IdPs that this SP is allowed to use; if unset, all listed IdPs may be used. If set, then the value is expected to be a list with entity identifiers for the allowed IdPs. A typical configuration, when the allowed set of IdPs are limited, would look something like this:

"service": {
    "sp": {
        "idp": ["urn:mace:umu.se:saml:roland:idp"],
    }
}

In this case the SP has only one IdP it can use.

Attributes that this SP would like to receive from IdPs.

Example:

"service": {
    "sp": {
        "optional_attributes": ["title"],
    }
}

Since the attribute names used here are the user friendly ones an attribute map must exist, so that the server can use the full name when communicating with other servers.

Attributes that this SP demands to receive from IdPs.

Example:

"service": {
    "sp": {
        "required_attributes": ["surname", "givenName", "mail"],
    }
}

Again as for optional_attributes the names given are expected to be the user friendly names.

Indicates if this SP wants the IdP to send the assertions signed. This sets the WantAssertionsSigned attribute of the SPSSODescriptor node of the metadata so the IdP will know this SP preference.

Valid values are “true” or “false”. Default value is “true”.

Example:

"service": {
    "sp": {
        "want_assertions_signed": "true",
    }
}

Where the endpoints for the services provided are. This directive has as value a dictionary with one or more of the following keys:

• artifact_resolution_service (aa, idp and sp)
• assertion_consumer_service (sp)
• assertion_id_request_service (aa, idp)
• attribute_service (aa)
• manage_name_id_service (aa, idp)
• name_id_mapping_service (idp)
• single_logout_service (aa, idp, sp)
• single_sign_on_service (idp)

The values per service is a list of tuples containing endpoint and binding type.

Example:

"service":
    "idp": {
        "endpoints" : {
            "single_sign_on_service" : [
                    ("http://localhost:8088/sso", BINDING_HTTP_REDIRECT)],
            "single_logout_service": [
                    ("http://localhost:8088/slo", BINDING_HTTP_REDIRECT)]
        },
    },
},

Indicates if this entity will sign the Logout Requests originated from it.

This can be overriden by application code for a specific call.

Valid values are “true” or “false”. Default value is “false”.

Example:

"service": {
    "sp": {
        "logout_requests_signed": "true",
    }
}

The name of a database where the map between a local identifier and a distributed identifier is kept. By default this is a shelve database. So if you just specify name, then a shelve database with that name is created. On the other hand if you specify a tuple then the first element in the tuple specifies which type of database you want to use and the second element is the address of the database.

Example:

"subject_data": "./idp.subject.db",

or if you want to use for instance memcache:

"subject_data": ("memcached", "localhost:12121"),

shelve and memcached are the only database types that are presently supported.

Gives information about common identifiers for virtual_organizations:

"virtual_organization" : {
    "urn:mace:example.com:it:tek":{
        "nameid_format" : "urn:oid:1.3.6.1.4.1.1466.115.121.1.15-NameID",
        "common_identifier": "umuselin",
    }
},

Keys in this dictionary are the identifiers for the virtual organizations. The arguments per organization are ‘nameid_format’ and ‘common_identifier’. Useful if all the IdPs and AAs that are involved in a virtual organization have common attribute values for users that are part of the VO.