hazza/resourcespace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

first commit

Browse Source
This commit is contained in:
Hendra Go
2025-07-18 16:20:14 +07:00
commit 98af45c018
16382 changed files with 3148096 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
plugins/simplesaml/lib/modules/saml/docs/authproc_authncontextclassref.md Normal file
View File

@@ -0,0 +1,14 @@
`saml:AuthnContextClassRef`
===========================
IDP-side filter for setting the `AuthnContextClassRef` element in the authentication response.
Examples
--------
'authproc.idp' => [
92 => [
'class' => 'saml:AuthnContextClassRef',
'AuthnContextClassRef' => 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport',
],
],

22
plugins/simplesaml/lib/modules/saml/docs/authproc_expectedauthncontextclassref.md Normal file
View File

@@ -0,0 +1,22 @@
`saml:ExpectedAuthnContextClassRef`
===================
SP side attribute filter to validate AuthnContextClassRef.
This filter checks the AuthnContextClassRef in the authentication response, and accepts or denies the access depending on the provided strength measure of authentication from IdP.
You can list the accepted authentitcation context values in the Service Provider configuration file.
If the given AuthnContextClassRef does not match any accepted value, the user will be redirected to an error page. It's useful to harmonize the SP's requested AuthnContextClassRef (another authproc filter), but you can accept more authentication strength measures than you requested for.
Examples
--------
'authproc.sp' => [
91 => [
'class' => 'saml:ExpectedAuthnContextClassRef',
'accepted' => [
'urn:oasis:names:tc:SAML:2.0:post:ac:classes:nist-800-63:3',
'urn:oasis:names:tc:SAML:2.0:ac:classes:Password',
],
],
],

28
plugins/simplesaml/lib/modules/saml/docs/authproc_pairwiseid.md Normal file
View File

@@ -0,0 +1,28 @@
`saml:PairwiseID`
===================
Filter to insert a pairwise-id that complies with the
[SAML V2.0 Subject Identifier Attributes Profile][specification].
[specification]: http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.pdf
This filter will take an attribute and a scope as input and transforms this
into a anonymized and scoped identifier that is globally unique for a given
user & service provider combination.
Note:
Since the subject-id is specified as single-value attribute, only the first
value of `identifyingAttribute` and `scopeAttribute` are considered.
Examples
--------
```php
'authproc' => [
50 => [
'class' => 'saml:PairwiseID',
'identifyingAttribute' => 'uid',
'scopeAttribute' => 'scope',
],
],
```

35
plugins/simplesaml/lib/modules/saml/docs/authproc_subjectid.md Normal file
View File

@@ -0,0 +1,35 @@
`saml:SubjectID`
===================
Filter to insert a subject-id that complies with the
[SAML V2.0 Subject Identifier Attributes Profile][specification].
[specification]: http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.pdf
This filter will take an attribute and a scope as input and transforms this
into a scoped identifier that is globally unique for a given user.
**Note**
If privacy is of your concern, you may want to hash the unique part of the subject-id. Hashing also ensures
that the output is compliant with the specification. If you do not want to hash the unique part, you _have_
to ensure that the `identifyingAttribute` always contains a value that is in line with the specification!
If you are also worried about correlation of IDs between diffent SP's, use the PairwiseID-filter instead.
**Note**
Since the subject-id is specified as single-value attribute, only the first
value of `identifyingAttribute` and `scopeAttribute` are considered.
Examples
--------
```php
'authproc' => [
50 => [
'class' => 'saml:SubjectID',
'identifyingAttribute' => 'uid',
'scopeAttribute' => 'scope',
'hashed' => true,
],
],
```

73
plugins/simplesaml/lib/modules/saml/docs/filterscopes.md Normal file
View File

@@ -0,0 +1,73 @@
Scoped Attributes Filtering
===========================
This document describes the **FilterScopes** attribute filter in the saml module.
This filter allows a Service Provider to make sure the scopes included in the values
of certain attributes correspond to what the Identity Provider declares in its
metadata. If the IdP includes a list of scopes in the metadata, only those scopes will
be allowed. On the other hand, if no scopes are declared or the scope is not included
in the list of declared scopes, it will be matched against the domain used by the
SAML `SingleSignOnService` endpoint. This means the `example.com` scope will be
allowed in attributes received from an IdP whose `SingleSignOnService` endpoint
is located on the `example.com` top domain or any subdomain of that. Such scope will
be rejected though if the match with the IdP's endpoint does not happen at the top
level, like for example with `example.com.domain.net`.
If you are configuring the metadata of an IdP manually, remember to add an array
to it with the key `scope`, containing the list of scopes expected from that entity.
Configuration
-------------
This filter can be configured in the `config/authsources.php` file, inside the
`authproc` array of the corresponding SAML authentication source in use.
Note that this filter **can only be used with SAML authentication sources**.
Here are the options available for the filter:
`attributes`
: An array containing a list of attributes that are scoped and therefore should be evaluated.
Defaults to _eduPersonPrincipalName_ and _eduPersonScopedAffiliation_.
Examples
--------
Basic configuration:
```php
'authproc' => [
90 => [
'class' => 'saml:FilterScopes',
],
],
```
Specify `mail` and `eduPersonPrincipalName` as scoped attributes:
```php
'authproc' => [
90 => [
'class' => 'saml:FilterScopes',
'attributes' => [
'mail',
'eduPersonPrincipalName',
],
],
],
```
Specify the same attributes in OID format:
```php
'authproc' => [
90 => [
'class' => 'saml:FilterScopes',
'attributes' => [
'urn:oid:0.9.2342.19200300.100.1.3',
'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
],
],
],
```

123
plugins/simplesaml/lib/modules/saml/docs/keyrollover.md Normal file
View File

@@ -0,0 +1,123 @@
# Key rollover with SimpleSAMLphp
This document gives a quick guide to doing key rollover with a SimpleSAMLphp service provider or identity provider.
## Background
A key rollover must perform several steps so that authentication does not break while remote SPs and IdPs learn about the new certificate. If you follow this procedure there should be no need for a synchronised switchover moment. It takes the following steps, which are detailed below:
1. You generate a new keypair for your entity to use.
2. You configure both old and new key in your SimpleSAMLphp config. Your
entity publishes metadata with two certificates in it. Meanwhile it continues to sign with the old key.
3. Relying parties (remote SPs or IdPs) refresh your metadata and will hence thereby trust the two listed certs (old and new). If they do not automatically refresh metadata their config needs to be updated manually to trust both the old and new certificate.
4. Once all relying parties have updated metadata with both certificates, you remove old certificate from your SimpleSAMLphp configuration, effectively doing the actual key rollover. Your SimpleSAMLphp now signs with the new key. Everything remains working because all relying parties will trust old and new certificate.
5. Your SimpleSAMLphp now publishes metadata with only the new cert. Relying parties will refresh metadata and drop the old certificate, not trusting it anymore (or remove the old certificate from their config manually). This last step is essential to ensure that the old certificate is actually distrusted.
## The steps
### Create the new key and certificate
First you must create the new key that you are going to use.
To create a self signed certificate, you may use the following command:
```bash
cd cert
openssl req -newkey rsa:3072 -new -x509 -days 3652 -nodes -out new.crt -keyout new.pem
```
### Add the new key to SimpleSAMLphp
Where you add the new key depends on whether you are doing key rollover for a service provider or an identity provider.
If you are doing key rollover for a service provider, the new key must be added to `config/authsources.php`.
To do key rollover for an identity provider, you must add the new key to `metadata/saml20-idp-hosted.php`.
If you are changing the keys for both an service provider and identity provider at the same time, you must update both locations.
The new certificate, private key and private key passphrase are added to the configuration with the prefix `new_`:
When the new key is added, SimpleSAMLphp will attempt to use both the new key and the old key for decryption of messages, but only the old key will be used for signing messages.
The metadata will be updated to list the new key for signing and encryption, and the old key will no longer listed as available for encryption.
This ensures that both those entities that use your old metadata and those that use your new metadata will be able to send and receive messages from you.
**Examples**:
In `config/authsources.php`:
```php
'default-sp' => [
'saml:SP',
'privatekey' => 'old.pem',
'certificate' => 'old.crt',
// When private key is passphrase protected.
'privatekey_pass' => '<old-secret>',
'new_privatekey' => 'new.pem',
'new_certificate' => 'new.crt',
// When new private key is passphrase protected.
'new_privatekey_pass' => '<new-secret>',
],
```
In `metadata/saml20-idp-hosted.php`:
```php
$metadata['urn:x-simplesamlphp:idp'] = [
'host' => '__DEFAULT__',
'auth' => 'example-userpass',
'privatekey' => 'old.pem',
'certificate' => 'old.crt',
// When private key is passphrase protected.
'privatekey_pass' => '<old-secret>',
'new_privatekey' => 'new.pem',
'new_certificate' => 'new.crt',
// When new private key is passphrase protected.
'new_privatekey_pass' => '<new-secret>',
];
```
### Distribute your new metadata
Now, you need to make sure that all your peers are using your new metadata.
How you go about this depends on how your peers have added your metadata.
If your peers are configured to automatically fetch the metadata directly from you, all you need to do is to wait for all of them to fetch the new metadata.
If you are part of an federation, you would probably either send it to the federation operators or use a federation tool to ask for the metadata to be updated.
Once the peers are using your new metadata, they will accept messages from you signed with either your old or your new key.
If they send encrypted messages to you, they will use your new key for encryption.
### Remove the old key
Once you are certain that all your peers are using the new metadata, you must remove the old key.
Replace the existing `privatekey`, `privatekey_pass` and `certificate` values op in your configuration with values from the `new_privatekey`, `new_privatekey_pass` and `new_certificate`, and remove the latter options..
This will cause your old key to be removed from your metadata.
**Examples**:
In `config/authsources.php`:
```php
'default-sp' => [
'saml:SP',
'certificate' => 'new.crt',
'privatekey' => 'new.pem',
// When private key is passphrase protected.
'privatekey_pass' => '<new-secret>',
],
In `metadata/saml20-idp-hosted.php`:
```php
$metadata['urn:x-simplesamlphp:idp'] = [
'host' => '__DEFAULT__',
'auth' => 'example-userpass',
'certificate' => 'new.crt',
'privatekey' => 'new.pem',
// When private key is passphrase protected.
'privatekey_pass' => '<new-secret>',
];
```
### Distribute your final metadata
Now you need to update the metadata of all your peers again, so that your old signing certificate is removed.
This will cause those entities to no longer accept messages signed using your old key.

157
plugins/simplesaml/lib/modules/saml/docs/nameid.md Normal file
View File

@@ -0,0 +1,157 @@
# NameID generation filters
This document describes the NameID generation filters in the saml module.
## Common options
`NameQualifier`
: The NameQualifier attribute for the generated NameID.
This can be a string that is used as the value directly.
It can also be `true`, in which case we use the IdP entity ID as the NameQualifier.
If it is `false`, no NameQualifier will be included.
: The default is `false`, which means that we will not include a NameQualifier by default.
`SPNameQualifier`
: The SPNameQualifier attribute for the generated NameID.
This can be a string that is used as the value directly.
It can also be `true`, in which case we use the SP entity ID as the SPNameQualifier.
If it is `false`, no SPNameQualifier will be included.
: The default is `true`, which means that we will use the SP entity ID.
## `saml:AttributeNameID`
Uses the value of an attribute to generate a NameID.
**Options**:
`identifyingAttribute`
: The name of the attribute we should use as the unique user ID.
`Format`
: The `Format` attribute of the generated NameID.
## `saml:PersistentNameID`
Generates a persistent NameID with the format `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`.
The filter will take the user ID from the attribute described in the `identifyingAttribute` option, and hash it with the `secretsalt` from `config.php`, and the SP and IdP entity ID.
The resulting hash is sent as the persistent NameID.
**Options**:
`identifyingAttribute`
: The name of the attribute we should use as the unique user ID.
## `saml:TransientNameID`
Generates a transient NameID with the format `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`.
No extra options are available for this filter.
## `saml:SQLPersistentNameID`
Generates and stores persistent NameIDs in a SQL database.
This filter generates and stores a persistent NameID in a SQL database.
To use this filter, either specify the `store` option and a database,
or configure SimpleSAMLphp to use a SQL datastore.
See the `store.type` configuration option in `config.php`.
**Options**:
`identifyingAttribute`
: The name of the attribute we should use as the unique user ID.
`allowUnspecified`
: Whether a persistent NameID should be created if the SP does not specify any NameID format in the request.
The default is `false`.
`allowDifferent`
: Whether a persistent NameID should be created if there are only other NameID formats specified in the request or the SP's metadata.
The default is `false`.
`alwaysCreate`
: Whether to ignore an explicit `AllowCreate="false"` in the authentication request's NameIDPolicy.
The default is `false`, which will only create new NameIDs when the SP specifies `AllowCreate="true"` in the authentication request.
`store`
: An array of database options passed to `\SimpleSAML\Database`, keys prefixed with `database.`.
The default is `[]`, which uses the global SQL datastore.
Setting both `allowUnspecified` and `alwaysCreate` to `true` causes `saml:SQLPersistentNameID` to behave like `saml:PersistentNameID` (and other NameID generation filters), at the expense of creating unnecessary entries in the SQL datastore.
## `saml:PersistentNameID2TargetedID`
Stores a persistent NameID in the `eduPersonTargetedID`-attribute.
This filter is not actually a NameID generation filter.
Instead, it takes a persistent NameID and adds it as an attribute in the assertion.
This can be used to set the `eduPersonTargetedID`-attribute to the same value as the persistent NameID.
**Options**:
`attribute`
: The name of the attribute we should store the result in.
The default is `eduPersonTargetedID`.
`nameId`
: Whether the generated attribute should be an saml:NameID element.
The default is `true`.
**Example**:
This example makes three NameIDs available:
'authproc' => [
1 => [
'class' => 'saml:TransientNameID',
],
2 => [
'class' => 'saml:PersistentNameID',
'identifyingAttribute' => 'eduPersonPrincipalName',
],
3 => [
'class' => 'saml:AttributeNameID',
'identifyingAttribute' => 'mail',
'Format' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
],
],
Storing persistent NameIDs in a SQL database:
'authproc' => [
1 => [
'class' => 'saml:TransientNameID',
],
2 => [
'class' => 'saml:SQLPersistentNameID',
'identifyingAttribute' => 'eduPersonPrincipalName',
],
],
Generating Persistent NameID and eduPersonTargetedID.
'authproc' => [
// Generate the persistent NameID.
2 => [
'class' => 'saml:PersistentNameID',
'identifyingAttribute' => 'eduPersonPrincipalName',
],
// Add the persistent to the eduPersonTargetedID attribute
60 => [
'class' => 'saml:PersistentNameID2TargetedID',
'attribute' => 'eduPersonTargetedID', // The default
'nameId' => true, // The default
],
// Use OID attribute names.
90 => [
'class' => 'core:AttributeMap',
'name2oid',
],
],
// The URN attribute NameFormat for OID attributes.
'attributes.NameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
'attributeencodings' => [
'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw', /* eduPersonTargetedID with oid NameFormat is a raw XML value */
],

67
plugins/simplesaml/lib/modules/saml/docs/nameidattribute.md Normal file
View File

@@ -0,0 +1,67 @@
`saml:NameIDAttribute`
======================
Filter that extracts the NameID we received in the authentication response and adds it as an attribute.
Parameters
----------
`attribute`
: The name of the attribute we should create.
The default is `nameid`.
`format`
: The format string for the attribute.
The default is `%I!%S!%V`.
The format string accepts the following replacements:
* `%I`: The IdP that issued the NameID.
This will be the `NameQualifier` element of the NameID if it is present, or the entity ID of the IdP we received the response from if not.
* `%S`: The SP the NameID was issued to.
This will be the `SPNameQualifier` element of the NameID if it is present, or the entity ID of this SP otherwise.
* `%V`: The value of the NameID.
* `%F`: The format of the NameID.
* `%%`: Will be replaced with a single `%`.
Examples
--------
Minimal configuration:
'default-sp' => [
'saml:SP',
'authproc' => [
20 => 'saml:NameIDAttribute',
],
],
Custom attribute name:
'default-sp' => [
'saml:SP',
'authproc' => [
20 => [
'class' => 'saml:NameIDAttribute',
'attribute' => 'someattributename',
],
],
],
Only extract the value of the NameID.
'default-sp' => [
'saml:SP',
'authproc' => [
20 => [
'class' => 'saml:NameIDAttribute',
'format' => '%V',
],
],
],
See also
--------
* [The description of the `saml:SP` authentication source.](../saml:sp)
* [How to generate various NameIDs on the IdP.](../saml:nameid)

483
plugins/simplesaml/lib/modules/saml/docs/sp.md Normal file
View File

@@ -0,0 +1,483 @@
# `saml:SP`
This authentication source is used to authenticate against SAML 2 IdPs.
## Metadata
The metadata for your SP will be available from the federation page on your SimpleSAMLphp installation.
SimpleSAMLphp supports generating metadata with the MDUI and MDRPI metadata extensions
and with entity attributes. See the documentation for those extensions for more details:
* [MDUI extension](../simplesamlphp-metadata-extensions-ui)
* [MDRPI extension](../simplesamlphp-metadata-extensions-rpi)
* [Attributes extension](../simplesamlphp-metadata-extensions-attributes)
**Parameters**:
These are parameters that can be used at runtime to control the authentication.
All these parameters override the equivalent option from the configuration.
`saml:AuthnContextClassRef`
: The AuthnContextClassRef that will be sent in the login request.
`saml:AuthnContextComparison`
: The Comparison attribute of the AuthnContext that will be sent in the login request.
This parameter won't be used unless `saml:AuthnContextClassRef` is set and contains one or more values.
Possible values:
* `SAML2\Constants::COMPARISON_EXACT` (default)
* `SAML2\Constants::COMPARISON_BETTER`
* `SAML2\Constants::COMPARISON_MINIMUM`
* `SAML2\Constants::COMPARISON_MAXIMUM`
`ForceAuthn`
: Force authentication allows you to force re-authentication of users even if the user has a SSO session at the IdP.
`saml:idp`
: The entity ID of the IdP we should send an authentication request to.
`isPassive`
: Send a passive authentication request.
`IDPList`
: List of IdP entity ids that should be sent in the AuthnRequest to the IdP in the IDPList element, part of the
Scoping element.
`saml:Extensions`
: The samlp:Extensions (an XML chunk) that will be sent in the login request.
`saml:logout:Extensions`
: The samlp:Extensions (an XML chunk) that will be sent in the logout request.
`saml:NameID`
: Add a Subject element with a NameID to the SAML AuthnRequest for the IdP.
This must be a \SAML2\XML\saml\NameID object.
`saml:NameIDPolicy`
: The format of the NameID we request from the IdP: an array in the form of
`[ 'Format' => the format, 'AllowCreate' => true or false ]`.
Set to an empty array `[]` to omit sending any specific NameIDPolicy element
in the AuthnRequest.
`saml:Audience`
: Add a Conditions element to the SAML AuthnRequest containing an
AudienceRestriction with one or more audiences.
## Authentication data
Some SAML-specific attributes are available to the application after authentication.
To retrieve these attributes, the application can use the `getAuthData()`-function from the [SP API](./simplesamlphp-sp-api).
The following attributes are available:
`saml:sp:IdP`
: The entityID of the IdP the user is authenticated against.
`saml:sp:NameID`
: The NameID the user was issued by the IdP.
This is a \SAML2\XML\saml\NameID object with the various fields from the NameID.
`saml:sp:SessionIndex`
: The SessionIndex we received from the IdP.
**Options**:
`acs.Bindings`
: List of bindings the SP should support. If it is unset, all will be added.
: Possible values:
* `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`
* `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact`
* `urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser`
`assertion.encryption`
: Whether assertions received by this SP must be encrypted. The default value is `false`.
If this option is set to `true`, unencrypted assertions will be rejected.
: Note that this option can be overridden for a specific IdP in saml20-idp-remote.
`AssertionConsumerService`
: List of Assertion Consumer Services in the generated metadata.
Specified in the format detailed in the
[Metadata endpoints](./simplesamlphp-metadata-endpoints) documentation.
Note that this list is taken at face value, so it's not useful to
list anything here that the SP auth source does not actually
support (unless the URLs point externally).
`AssertionConsumerServiceIndex`
: The Assertion Consumer Service Index to be used in the AuthnRequest in place of the Assertion
Service Consumer URL.
`attributes`
: List of attributes this SP requests from the IdP.
This list will be added to the generated metadata.
: The attributes will be added without a `NameFormat` by default.
Use the `attributes.NameFormat` option to specify the `NameFormat` for the attributes.
: An associative array can be used, mixing both elements with and without keys. When a key is
specified for an element of the array, it will be used as the friendly name of the attribute
in the generated metadata.
: *Note*: This list will only be added to the metadata if the `name`-option is also specified.
`attributes.NameFormat`
: The `NameFormat` for the requested attributes.
`attributes.index`
: The `index` attribute that is set in the md:AttributeConsumingService element. Integer value that defaults to `0`.
`attributes.isDefault`
: If present, sets the `isDefault` attribute in the md:AttributeConsumingService element. Boolean value, when
unset, the attribute will be omitted.
`attributes.required`
: If you have attributes added you can here specify which should be marked as required.
: The attributes should still be present in `attributes`.
`AuthnContextClassRef`
: The SP can request authentication with one or more specific authentication context classses.
One example of usage could be if the IdP supports both username/password authentication as well as software-PKI.
Set this to a string for one class identifier or an array of requested class identifiers.
`AuthnContextComparison`
: The Comparison attribute of the AuthnContext that will be sent in the login request.
This parameter won't be used unless `saml:AuthnContextClassRef` is set and contains one or more values.
Possible values:
* `SAML2\Constants::COMPARISON_EXACT` (default)
* `SAML2\Constants::COMPARISON_BETTER`
* `SAML2\Constants::COMPARISON_MINIMUM`
* `SAML2\Constants::COMPARISON_MAXIMUM`
`authproc`
: Processing filters that should be run after SP authentication.
See the [authentication processing filter manual](simplesamlphp-authproc).
`certData`
: Base64 encoded certificate data. Can be used instead of the `certificate` option.
`certificate`
: File name of certificate for this SP. This certificate will be included in generated metadata.
`contacts`
: Specify contacts in addition to the `technical` contact configured through `config/config.php`.
: For example, specifying a support contact:
'contacts' => [
[
'contactType' => 'support',
'emailAddress' => 'support@example.org',
'givenName' => 'John',
'surName' => 'Doe',
'telephoneNumber' => '+31(0)12345678',
'company' => 'Example Inc.',
],
],
: Valid values for `contactType` are: `technical`, `support`, `administrative`, `billing` and `other`. All
fields, except `contactType` are OPTIONAL.
`description`
: A description of this SP.
Will be added to the generated metadata, in an AttributeConsumingService element.
: This option can be translated into multiple languages by specifying the value as an array of language-code to translated description:
'description' => [
'en' => 'A service',
'no' => 'En tjeneste',
],
: *Note*: For this to be added to the metadata, you must also specify the `attributes` and `name` options.
`disable_scoping`
: Whether sending of samlp:Scoping elements in authentication requests should be suppressed. The default value is `false`.
When set to `true`, no scoping elements will be sent. This does not comply with the SAML2 specification, but allows
interoperability with ADFS which [does not support Scoping elements](https://docs.microsoft.com/en-za/azure/active-directory/develop/active-directory-single-sign-on-protocol-reference#scoping).
: Note that this option also exists in the IdP remote configuration. An entry
in the IdP-remote metadata overrides this the option in the SP
configuration.
`enable_unsolicited`
: Whether this SP is willing to process unsolicited responses. The default value is `true`.
`discoURL`
: Set which IdP discovery service this SP should use.
If this is unset, the IdP discovery service specified in the global option `idpdisco.url.saml20` in `config/config.php` will be used.
If that one is also unset, the builtin default discovery service will be used.
`encryption.blacklisted-algorithms`
: Blacklisted encryption algorithms. This is an array containing the algorithm identifiers.
: Note that this option can be set for each IdP in the [IdP-remote metadata](../simplesamlphp-reference-idp-remote).
`entityID`
: The entity ID this SP should use. (Must be set or an error will be generated.)
: The entity ID must be a URI, that is unlikely to change for technical or political
reasons. We recommend it to be a domain name, like above, if your organization's main
domain is `example.org` and this SP is for the application `myapp`.
The URL does not have to resolve to actual content, it's
just an identifier. Hence you don't need to and should not change it if the actual domain
of your application changes.
: For guidance in picking an entityID, see
[InCommon's best practice](https://spaces.at.internet2.edu/display/federation/saml-metadata-entityid)
on the matter.
`ForceAuthn`
: Force authentication allows you to force re-authentication of users even if the user has a SSO session at the IdP.
`idp`
: The entity ID this SP should connect to.
: If this option is unset, an IdP discovery service page will be shown.
`IsPassive`
: IsPassive allows you to enable passive authentication by default for this SP.
`key_name`
: The name of the certificate. It is possible the IDP requires your certificate to have a name.
If provided, it will be exposed in the SAML 2.0 metadata as `KeyName` inside the `KeyDescriptor`. This also requires a certificate to be provided.
`name`
: The name of this SP.
Will be added to the generated metadata, in an AttributeConsumingService element.
: This option can be translated into multiple languages by specifying the value as an array of language-code to translated name:
'name' => [
'en' => 'A service',
'no' => 'En tjeneste',
],,
: *Note*: You must also specify at least one attribute in the `attributes` option for this element to be added to the metadata.
`nameid.encryption`
: Whether NameIDs sent from this SP should be encrypted. The default
value is `false`.
: Note that this option can be set for each IdP in the [IdP-remote metadata](../simplesamlphp-reference-idp-remote).
`NameIDFormat`
: An array of the format(s) listed in the SP metadata that this SP will accept. Example:
'NameIDFormat' => [
\SAML2\Constants::NAMEID_PERSISTENT,
\SAML2\Constants::NAMEID_TRANSIENT,
],
`NameIDPolicy`
: The format of the NameID we request from the IdP in the AuthnRequest:
an array in the form of
`[ 'Format' => the format, 'AllowCreate' => true or false ]`.
Set to an empty array `[]` to omit sending any specific NameIDPolicy element
in the AuthnRequest. When the entire option or either array key is unset,
the defaults are transient and true respectively.
`OrganizationName`, `OrganizationDisplayName`, `OrganizationURL`
: The name and URL of the organization responsible for this IdP.
You need to either specify *all three* or none of these options.
: The Name does not need to be suitable for display to end users, the DisplayName should be.
The URL is a website the user can access for more information about the organization.
: This option can be translated into multiple languages by specifying the value as an array of language-code to translated name:
'OrganizationName' => [
'en' => 'Voorbeeld Organisatie Foundation b.a.',
'nl' => 'Stichting Voorbeeld Organisatie b.a.',
],
'OrganizationDisplayName' => [
'en' => 'Example organization',
'nl' => 'Voorbeeldorganisatie',
],
'OrganizationURL' => [
'en' => 'https://example.com',
'nl' => 'https://example.com/nl',
],
`privatekey`
: File name of private key to be used for signing messages and decrypting messages from the IdP. This option is only required if you use encrypted assertions or if you enable signing of messages.
`privatekey_pass`
: The passphrase for the private key, if it is encrypted. If the private key is unencrypted, this can be left out.
`ProviderName`
: Human readable name of the local SP sent with the authentication request.
`ProtocolBinding`
: The binding that should be used for SAML2 authentication responses.
This option controls the binding that is requested through the AuthnRequest message to the IdP.
By default the HTTP-Post binding is used.
`redirect.sign`
: Whether authentication requests, logout requests and logout responses sent from this SP should be signed. The default is `false`.
If set, the `AuthnRequestsSigned` attribute of the `SPSSODescriptor` element in SAML 2.0 metadata will contain its value. This
option takes precedence over the `sign.authnrequest` option in any metadata generated for this SP.
`redirect.validate`
: Whether logout requests and logout responses received by this SP should be validated. The default is `false`.
`RegistrationInfo`
: Allows to specify information about the registrar of this SP. Please refer to the
[MDRPI extension](../simplesamlphp-metadata-extensions-rpi) document for further information.
`RelayState`
: The page the user should be redirected to after an IdP initiated SSO.
`RequestInitiation`
: Enable the [Service Provider Request Initiation Protocol](https://wiki.oasis-open.org/security/RequestInitProtProf).
To validate the `target` the `trusted.url.domains` configuration option has to be used.
`saml.SOAPClient.certificate`
: A file with a certificate *and* private key that should be used when issuing SOAP requests from this SP.
If this option isn't specified, the SP private key and certificate will be used.
: This option can also be set to `false`, in which case no client certificate will be used.
`saml.SOAPClient.privatekey_pass`
: The passphrase of the privatekey in `saml.SOAPClient.certificate`.
`saml20.hok.assertion`
: Enable support for the SAML 2.0 Holder-of-Key SSO profile.
See the documentation for the [Holder-of-Key profile](./simplesamlphp-hok-sp).
`sign.authnrequest`
: Whether to sign authentication requests sent from this SP. If set, the `AuthnRequestsSigned` attribute of the
`SPSSODescriptor` element in SAML 2.0 metadata will contain its value.
: Note that this option also exists in the IdP-remote metadata, and
any value in the IdP-remote metadata overrides the one configured
in the SP configuration.
`sign.logout`
: Whether to sign logout messages sent from this SP.
: Note that this option also exists in the IdP-remote metadata, and
any value in the IdP-remote metadata overrides the one configured
in the SP configuration.
`signature.algorithm`
: The algorithm to use when signing any message generated by this service provider. Defaults to RSA-SHA256.
: Possible values:
* `http://www.w3.org/2000/09/xmldsig#rsa-sha1`
*Note*: the use of SHA1 is **deprecated** and will be disallowed in the future.
* `http://www.w3.org/2001/04/xmldsig-more#rsa-sha256`
The default.
* `http://www.w3.org/2001/04/xmldsig-more#rsa-sha384`
* `http://www.w3.org/2001/04/xmldsig-more#rsa-sha512`
`SingleLogoutServiceBinding`
: List of SingleLogoutService bindings the SP will claim support for (can be empty).
: Possible values:
* `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`
* `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`
* `urn:oasis:names:tc:SAML:2.0:bindings:SOAP`
`SingleLogoutServiceLocation`
: The Single Logout Service URL published in the generated metadata.
`validate.logout`
: Whether we require signatures on logout messages sent to this SP.
: Note that this option also exists in the IdP-remote metadata, and
any value in the IdP-remote metadata overrides the one configured
in the IdP metadata.
`WantAssertionsSigned`
: Whether assertions received by this SP must be signed. The default value is `false`.
The value set for this option will be used to set the `WantAssertionsSigned` attribute of the `SPSSODescriptor` element in
the exported SAML 2.0 metadata.
**Examples**:
Here we will list some examples for this authentication source.
### Minimal
'example-minimal' => [
'saml:SP',
'entityID' => 'https://myapp.example.org',
],
### Connecting to a specific IdP
'example' => [
'saml:SP',
'entityID' => 'https://myapp.example.org',
'idp' => 'https://example.net/saml-idp',
],
### Encryption and signing
This SP will accept encrypted assertions, and will sign and validate all messages.
'example-enc' => [
'saml:SP',
'entityID' => 'https://myapp.example.org',
'certificate' => 'example.crt',
'privatekey' => 'example.key',
'privatekey_pass' => 'secretpassword',
'redirect.sign' => true,
'redirect.validate' => true,
],
### Specifying attributes and required attributes
An SP that wants eduPersonPrincipalName and mail, where eduPersonPrincipalName should be listed as required:
'example-attributes => [
'saml:SP',
'entityID' => 'https://myapp.example.org',
'name' => [ // Name required for AttributeConsumingService-element.
'en' => 'Example service',
'no' => 'Eksempeltjeneste',
],
'attributes' => [
'eduPersonPrincipalName',
'mail',
// Specify friendly names for these attributes:
'sn' => 'urn:oid:2.5.4.4',
'givenName' => 'urn:oid:2.5.4.42',
],
'attributes.required' => [
'eduPersonPrincipalName',
],
'attributes.NameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:basic',
],
### Limiting supported AssertionConsumerService endpoint bindings
'example-acs-limit' => [
'saml:SP',
'entityID' => 'https://myapp.example.org',
'acs.Bindings' => [
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
],
],
### Requesting a specific authentication method
$auth = new \SimpleSAML\Auth\Simple('default-sp');
$auth->login([
'saml:AuthnContextClassRef' => 'urn:oasis:names:tc:SAML:2.0:ac:classes:Password',
]);
### Using samlp:Extensions
$dom = \SAML2\DOMDocumentFactory::create();
$ce = $dom->createElementNS('http://www.example.com/XFoo', 'xfoo:test', 'Test data!');
$ext[] = new \SAML2\XML\Chunk($ce);
$auth = new \SimpleSAML\Auth\Simple('default-sp');
$auth->login([
'saml:Extensions' => $ext,
]);