-
Notifications
You must be signed in to change notification settings - Fork 4
Roadmap 2022
New Years for businesses usually come with new goals. Our objective here is to do an assessment and inventory from a customer centric point of view of essential , important and critical features and issues to work on for the upcoming year. This assessment will then be used to set up a roadmap for Gluu SAML IDP.
In this section, we aggregate all of the information at hand in order to achieve our goal. These range from commonly reported issues by customers, to sought after features not yet implemented. This should also take account the relationship SAML IDP has with Gluu products in order to ensure alignment between SAML IDP and other Gluu products.
We receive various support tickets, and for the ones related to SAML IDP , a common issue faced by customers is that of error messages displayed on web pages which are not descriptive enough of the underlying issue. Although too much shouldn't be revealed that could expose vital data to attackers , there is a need to balance that security need with the needs of our customers to quickly resolve issues steming from this kind of errors. Alternatively, it would be good if these errors and their probable cause could be documented.
Another common set of support tickets received related to SAML IDP are tickets related to the customization and extension of SAML IDP functionality. Although this is generally done by our partners, there are some simple but vital extensions that could be part of our core offering. It would be nice if they could be identified and implemented.
There is an existing backlog of Github issues for the SAML IDP Project. It would be important to do some re-organization and prioritization.
In Gluu 4.x and below , SAML IDP has a dependency on the oxTrust project , relying on it both for UI management and generation of it's configuration files. If we are to support the Shib IDP in Gluu Flex, we'll need to write a config-api plugin and admin-ui plugin.
There are and always will be feature suggestions discussed in the chat by customers , or team members. It would be good to do a census of the important ones in order to see if they can fit into a release for 2022. An example would be a provision of various hooks that could be used to even finely control the authentication process by providing policy evaluation. Another one would be incremental additions to make our SAML IDP implementation multi-tenant.
The Shibboleth project is putting out a new version of Shibboleth IDP frequently these days, immediately deprecating the older version. These new versions come with new features and bugfixes customers are expecting to have in their production environment. We have to devise a means to always have the latest Shibboleth IDP version released
In this section , we will enumerate the issues/features we will work on alongside their priority and estimated completion time. This list will be continuously updated during the course of the year. Priorities have a value of 1 to 5 where 1 means low priority and 5 means highest priority.
- Priority Level:
5 - Estimated Completion Time:
1 day - Related Github issue(s): N/A
As of the drafting of this document , Gluu SAML IDP ships with Shibboleth
IDP version 4.1.4 which is also, as of the drafting of this document EOL
as of January 2022. There is therefore an imperative to upgrade to the latest
version which is 4.1.5. No major changes are expected, except for binary
updates. Configuration is expected to stay same.
- Priority Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): N/A
During startup or while Gluu SAML IDP is running , some common errors are encountered by customers. The objective of this work item is to document the most important ones, alongside a probable solution for customers.
- Priority Level:
2 - Estimated Completion Time:
N/A - Related Github issue(s): N/A
Shibboleth IDP 4.1.x introduced the concept of plugins to allow the introduction
of functionality into IDP in a pluggable way, that does not require lockstep
versioning with the IDP. We should leverage this to ease deployment , and break down
the features/extensions we've developped over the years into modules. It may also break
present us with a business opportunity as premium modules may be developped and made available
to preminum customers or upon direct purchase.
-
Priority Level:
1 -
Estimated Completion Time:
N/A -
Related Github issue(s): #115
Gluu supports many database backends and may support even more. Every time a new backend is introduced a lot of database backend related changes happen at the level of Shibboleth IDP. Gluu has an excellent project called
oxOrmwhich is an abstraction layer above our supported database backends. A wrapper could be written around it to have it serve as a DataConnector for Shibboleth IDP and reduce the integration effort for new (and existing) database backends.
- Priority Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #88
Gluu SAML IDP relies on generated configuration files. These configuration files are generated from velocity templates. Since Gluu 4.1.x , these configuration files have been moved into a jar, which then is packaged in the application war. This deployment structure makes it difficult (or tedious) to make changes to said files by customers. A means to allow for easier modifications should be devised.
- Priority Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #86
It would be nice if there was a way for a Gluu admin to be able to set a default ACR for new SAML TR's.
- Priority Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #82
It would be nice if there was a way for a Gluu admin to be able to set a default ACR for new SAML TR's. If it's to be done on a per TR basis is still to be discussed.
- Priority Level:
3 - Estimated Completion Time:
N/A - Related Github issue(s): #82
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 Level:
3 - Estimated Completion Time:
N/A - Related Github issue(s): #82
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 Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #69
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 Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #69
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 Level:
4 - Estimated Completion Time:
N/A - Related Github issue(s): #63
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 Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #62
As much as a fix apparently exists for this issue , it hasn't been officially tested. We will make sure it works and then close the issue.
- Priority Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #62
As much as a fix apparently exists for this issue , it hasn't been officially tested. We will make sure it works and then close the issue.
- Priority Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #62
As much as a fix apparently exists for this issue , it hasn't been officially tested. We will make sure it works and then close the issue.
- Priority Level:
3 - Estimated Completion Time:
N/A - Related Github issue(s): #61 , #46
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 Level:
2 - Estimated Completion Time:
N/A - Related Github issue(s): #58
See issue #58 for more details.
- Priority Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #52 , #70
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 Level:
4 - Estimated Completion Time:
N/A - Related Github issue(s): #26
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 Level:
1 - Estimated Completion Time:
N/A - Related Github issue(s): #41
See issue #41 for more details.