-
Notifications
You must be signed in to change notification settings - Fork 4
Gluu Flex Migration
Gluu Flex is (going to be the next) evolution of the Gluu line of IAM products. It is based off of our new umbrella project called Janssen. Unfortunately, in Janssen, there is no equivalent to oxTrust. oxTrust did a lot of heavywork in the past to make sure oxShibboleth is properly configured before and after it runs. This means, if we have to migrate oxShibboleth to work on Gluu Flex , we will have to replace every high level functionality provided by oxTrust and also replace references to Gluu 4 referenced in oxShibboleth itself. This also is an opportunity to perform some enhancements and introduce additional features. It is to note that the changes may not be backwards compatible with oxShibboleth in Gluu 4. This document will contain our migration plan including results of our investigations.
We will need a new name for oxShibboleth in Gluu Flex. None has been given so far. It would be good if it were a different name as this migration will branch (probably) irreversibly away from it's parent project.
We have identified the following areas which will constitute our migration work items:
oxShibboleth currently contains a sub-module called shib-oxauth-authn. It contains the business logic allowing
Shibboleth IDP to talk to oxAuth. It also relies on oxAuth libraries to collect user information. References to
oxAuth within this project will have to be changed to references to jans-auth. Also , this contains code that
invokes interception scripts. Those interception scripts will have to be changed , probably, new method signatures
will have to be introduced in order to properly abstract away IDP structures these scripts are supposed to work with.
We also have a new project called Agama. It would be nice if it's use could be extended to our case.
Shibboleth IDP , since version 4 has introduced new and better configuration semantics. It would be a good time and place to introduce them. One of those configuration files which have changed are the Metadata configuration files. Attribute resolution configuration was changed too, as of version 4 of Shibboleth IDP. We started the migration, but this would be a good time to finish.
oxShibboleth IDP relies on oxTrust to generate and update configuration files from templates. This process will have to be moved from oxTrust. Probably integrated into oxShibboleth. This is contingent on how from now henceforth configuration storage will be done. More on that later.
We support various databases , which are used to persist the value of attributes used in SAML. We use existing connectors
for each and everyone of them, meaning each time a new DB is introduced , extra effort has to be made to support it in Shibboleth IDP,
especially for configuration files. In addition , there are corner cases (multivalue attributes) that require some special tweaking.
The solution to deal with the issue once and for all would be to create our own custom connector based on jans-orm.
This is experimental , but in line with 3.3 , we will be investigating a means to integrate configuration loading directly into
Shibboleth IDP. It may just make a better alternative to Jackrabbit.