...
The IdP has a couple of built-in methods (called "strategies" in the configuration) to produce this kind of identifier. The strategy used is controlled with the idp.persistentId.generator property in saml-nameid.properties.
| Warning |
|---|
It's recently come to light that at least some (perhaps many, or even most) applications do not support case-sensitive handling of identifiers. This SAML format is explicitly defined to be case-sensitive, but it is much, much wiser not to expect that. As a result, all current Older versions of the software generate identifiers that would not be wise to use in practicewith the Base64 encoding and this is much less safe, so if you're not already supporting identifiers produced by itthem, you would be wise to either wait for the next update, or to incorporate a different strategy to generate the values that relies on using a Base32 encoding, which is designed to support case-insensitive applications. This capability will be built-in to the next version of the software and enabled by default for new deploymentsNew installs include a property explicitly set to produce Base32 values, but upgrades will continue to use Base64 for compatibility reasons. |
Enabling the Generator
To enable either approach, you will need to uncomment the generator bean in saml-nameid.xml for SAML 2 once you set the appropriate properties highlighted below.
...
- The idp.persistentId.generator property needs to be set to "shibboleth.StoredPersistentIdGenerator".
- Either the idp.persistentId.dataSource 3.2 or idp.persistentId.store properties must be set to the name of a bean you must define. You can place it in saml-nameid.xml if you like (anywhere at the "top" level of the file). The former property is used to specify a JDBC DataSource object to use for storage, with the rest of the settings defaulted. If you want to override some of the settings available, latter property can be used to point to a bean that inherits from a bean of type JDBCPersistentIdStoreExparent bean named "shibboleth.JDBCPersistentIdStore", as shown below.
A default feature of the stored strategy is that it uses the computed strategy to produce the initial identifier for each subject, to help with migration. If you don't need that to happen, you can set the idp.persistentId.computed property to an empty value and ignore that feature entirely. This is recommended for anybody not already supporting identifiers produced with the other strategy.
| Note |
|---|
It's not a good idea to define a single shared DataSource bean between this feature and, for example, the JPA StorageService feature, even if you happen to use one database for both. The reason is that you don't want "non-essential" features like consent potentially interfering with the more essential use here. Separate DataSource beans will keep the pools of connections separate and prevent problems in one component from breaking the other. |
Examples of each type of bean using an unspecified database and the DBCP2 pooling library (not provided with the IdP) follows. You will need to determine what driver class to plug into the bean definition for your database and the proper URL to use. Always use current drivers when possible; bug fixes for obscure problems tend to be frequent. When in doubt, grab a newer one.
...