...
- 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 of type JDBCPersistentIdStoreExthat inherits from a parent 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.
...