Table of Contents | ||||
---|---|---|---|---|
|
Note |
---|
Draft until official release of 1.1.0 |
Some changes in the persistence layer need to be reflected in the database used by Syncope as internal repository.
Relevant changes
Role provisioning
Role provisioning (provided by SYNCOPE-172 and related) changed the way how the schema mapping is stored by removing the SchemaMapping
table and introducing the following new tables:
UMapping
UMappingItem
RMapping
RMappingItem
Changes in the REST interface
More details in the dedicated page.
MD5
...
not supported any more
SYNCOPE-51 removed MD5 from supported password cipher algorithm.
...
Code Block |
---|
connRequestTimeout INTEGER |
...
Changes in ExternalResource table
ExternalResource.forceMandatoryConstraint
renamed to asExternalResource.enforceMandatoryCondition
- ExternalResource has now an additional column
Code Block actionsClassName VARCHAR(255)
Changes in Entitlement table
- SYNCOPE-319 introduced the new
CONNECTOR_RELOAD
entitlement - SYNCOPE-331 renamed
RESOURCE_GETOBJECT
asRESOURCE_GETCONNECTOROBJECT
Suggested procedure
Make the TODO tab empty
- Approve or reject any pending approval
- Manage any pending user request
Backup
Make full backup of
- the internal storage
- your 1.0.X project's (the one created from archetype) sources
- configured bundles and logs directories
The new 1.1.X project
- create a new 1.1.X project
- copy any existing Java class you have developed for the former 1.0.X project and make necessary adaptations
- include any connector bundle you might have added in the former 1.0.X project
- configure the internal storage as done for the former 1.0.X project
Build, deploy and run
This first run will barely upgrade the existing SQL schema in the internal storage: you will notice many exceptions in the logs files, just ignore.
Once the core application has started (check this from the log files), stop the JEE container.
Perform custom SQL upgrade
At this point you need to manually perform some SQL changes according to the description above.
An example of such changes is reported in the attached sample for MySQL: the set of SQL statements you need to run vary depending on the DBMS used for internal storage.
Enable ContentUpgrader
In core/src/main/resources/syncopeContext.xml
add
Code Block |
---|
<bean class="org.apache.syncope.core.init.SpringContextInitializer">
<property name="upgrade" value="true"/>
</bean>
|
Enable SyncopeMD5FallbackAuthenticationProvider
If some of existing users have MD5
passwords and you want them being able to log in without prior changing their password, modify in core/src/main/resources/securityContext.xml
Code Block |
---|
<bean id="syncopeAuthenticationProvider"
class="org.apache.syncope.core.security.SyncopeAuthenticationProvider">
<property name="adminUser" value="${adminUser}"/>
<property name="adminPassword" value="${adminPassword}"/>
<property name="adminPasswordAlgorithm" value="${adminPasswordAlgorithm}"/>
<property name="syncopeUserDetailsService" ref="syncopeUserDetailsService"/>
</bean>
|
to
Code Block |
---|
<bean id="syncopeAuthenticationProvider"
class="org.apache.syncope.core.security.SyncopeMD5FallbackAuthenticationProvider">
<property name="adminUser" value="${adminUser}"/>
<property name="adminPassword" value="${adminPassword}"/>
<property name="adminPasswordAlgorithm" value="${adminPasswordAlgorithm}"/>
<property name="syncopeUserDetailsService" ref="syncopeUserDetailsService"/>
</bean>
|
Once all of your users have changed their password, you can restore the original configuration.
SyncopeMD5FallbackAuthenticationProvider
can also be taken as reference to implement more sophisticated handling of existing MD5 passwords.
Build, deploy and run
This second run should succeed without logging any exception.
You should now have full access to all Syncope features.
Stop the JEE container
Disable ContentUpgrader
In core/src/main/resources/syncopeContext.xml
remove
Code Block |
---|
<bean class="org.apache.syncope.core.init.SpringContextInitializer">
<property name="upgrade" value="false"/>
</bean>
|
Build, deploy and run
This final run can be considered as definitive: only, if you configured SyncopeMD5FallbackAuthenticationProvider
or similar, consider planning its removal in the near future, maybe once all users have changed their password.