-
Notifications
You must be signed in to change notification settings - Fork 4
Updated Roadmap and Migration Plan to Flex
Back in January, a roadmap for oxShibboleth was established. Some of the items on this list were completed , most were not. In addition , there has been an increasing demand for a Shibboleth based solution in Gluu Flex. A document was produced too but with no clear execution plan. The goal of this document is to consolidate both and provide a clear roadmap ahead for oxShibboleth and it's equivalent in Gluu Flex. Work will be divided in tasks. Each task will be assigned a task group and an iteration. Task groups put together related tasks. Iterations group tasks in terms of schedule (which group of tasks to work on next).
In this section, we will outline each task. Each task is associated to a task group that helps identify related tasks, and also to an iteration group , that helps schedule tasks (probably by importance and/or urgency).
- Priority:
- Task Group:
- Iteration:
- Duration:
The objective of this task is to go through some SAML related support tickets and identify some commonly encountered use cases and runtime error messages. These error messages or use cases and their associated solutions will be added to the current documentation as an FAQ section. Care should be taken not to include common use cases requiring development of enhanced features as these will be or should be handled by our partners.
v
- Priority
- Task Group:
- Iteration:
- Duration:
The objective of this task is to perform upgrades of Shibboleth SAML IDP to the latest version. It is important from a feature and even more so from a security standpoint. Instead of opening a ticket each and every time an upgrade is needed, the following is suggested:
- A ticket will be open permanently for the purpose at hand it
- Check for new releases of Shibboleth IDP through the mailing list or other means. If a new release is found, create a comment under the issue created in step one.
- In the comment created above,stNah ate the version of Shibboleth IDP to upgrade to , and include the relevant links and potential areas impacted by the upgrade.
- Perform the upgrade
- Re-open the comment opened above and document major changes and impacted areas. This will be used by documentation writers.
- Repeat from step two.
-
Priority:
-
Task Group:
-
Iteration:
-
Duration:
Shibboleth IDP 4.1.x introduced the concepts of modules and plugins. Plugins allow functionalities to be introduced in Shibboleth IDP in a pluggable way that does not require lockstep versionning with the IDP. The objective of this task will be to leverage this and bundle every Gluu specific IDP piece of code as a plugin. This should modularize and simplify installation , even presenting a business opportunity to monetize some enhanced features that we may develop on the side.
- Priority:
- Task Group:
- Iteration:
- Duration
Gluu supports many a database backend and may support even more in the
future. This means every time a backend is added, support needs to be added
in Gluu SAML IDP. Gluu has an excellent project called oxOrm which is a
database abstraction layer used accross it's products. It could serve as a basis for a custom Shibboleth IDP DataConnector that will eliminate the need(s) to always have to add support for an extra database.
In it's current state, Shibboleth IDP relies on oxTrust to generate some of it's configuration files on the fly. Those files are currently in a jar, which makes them a bit hard to modify by customers. An easier approach should be devised.
Add the possibility for a user to set the default acr that will be used for a trust relationship. This will involve modifying the oxTrust UI and also in oxShibboleth.
- Priority:
- Task Group:
- Iteration:
- Duration
The default JKS keystore with CA certificates, cacerts, included with the JDK is not FIPS compliant. FIPS 140-2 requires a PKCS12 PBES2 keystore; JKS keystores and PKCS12 keystores created with keytool using the Sun JSSE provider (the default) are not supported. If you are using the default JDK cacerts keystore, you need to complete the following steps to ensure FIPS compliance:
- Convert the JDK cacerts keystore from JKS to PKCS12 format
- Convert the PKCS12 keystore using the RSA JCE provider to be FIPS compliant
- Set Java system properties to update the default trust store used by Java
- Priority:
- Task Group:
- Iteration:
- Duration:
Preliminary investigation shows CAS Apps are unable to participate in Shibboleth SLO and it may be due to a configuration issue. A fix needs to be issued. We don't have many customers using CAS , so this is not a high priority issue. This also may necessitate splitting this work item into two more (in case this requires a UI change).
- Priority:
- Task Group:
- Iteration:
- Duration:
InCommon has introduced MDQ for their metadata query lately, It will greatly help us to manage server resources. Work has already been done (but not tested) for the backend , but not much has been done on the frontend.
- Priority:
- Task Group:
- Iteration:
- Duration:
There is a (long) list of existing bugs that are to be fixed. That backlog needs to be cleared. A list of them will be outlined below:
- Missing Content-Type header on ssologout page
- Priority:
- Task Group:
- Iteration:
- Duration:
Front-channel (e.g. HTTP-Redirect) logout, works in standalone Shibboleth since version 3.2.0 Gluu 3.1.6. is using Shibboleth as an extension - i.e. during login it forwards authentication work to oxAuth. However, it seems that logout endpoints are not yet notifying oxAuth to destroy the user session on Gluu server.
- Priority:
- Task Group:
- Iteration:
- Duration:
See issue #58 for more details.
- Priority:
- Task Group:
- Iteration:
- Duration:
The current implementation of Shibboleth IDP does not support the back-channel logout functionality. Some specifications require that a logout happen over SOAP instead of front-channel SAML SLO flow. The Shibboleth IDP is implementing the functionality in their upcoming release and integrating that release would allow Gluu to leverage this feature.
- Priority:
- Task Group:
- Iteration:
- Duration:
Currently we load config from the filesystem. This makes it really hard to cluster... In Shib IDP v3 there is a way to load config from https. This would make our lives way easier.
- Priority:
- Task Group:
- Iteration:
- Duration:
See issue #41 for more details.
- Priority:
- Task Group:
- Iteration:
- Duration:
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.
- Priority:
- Task Group:
- Iteration:
- Duration:
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.
- Priority:
- Task Group:
- Iteration:
- Duration:
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.
- Priority:
- Task Group:
- Iteration:
- Duration:
This is experimental , but in line with 2-16 , we will be investigating a means to integrate configuration loading directly into Shibboleth IDP. It may just make a better alternative to Jackrabbit.