February 12th, 2020 by inflectra
As we get ready for the release of SpiraTest, SpiraTeam, and SpiraPlan 6.4 early next month, we'd like to introduce some of the new functionality that will be available in this release. This release includes two main features, plus lots of smaller enhancements and bug fixes. The two main marquee features are support for Single Sign On (SSO) using the industry standard OAuth 2.0 protocol, and some major enhancements to the Reports dashboard.
When you login to Spira, you normally enter in a login and password that is managed and stored specifically by Spira internally.
However, for larger enterprises, there is often a desire to centralize (for security and compliance reasons) the users that can access the various IT systems in the organization, and to have a central place to manage passwords and whether a user is allowed to access a specific system. Traditionally, for on-premise installations, the standard for this type of system is the Lightweight Directory Access Protocol (LDAP). This protocol is used when you want to connect Spira to a company directory server, such as Microsoft Active Directory, or another directory system such as OpenLDAP.
However when you are using Spira in the cloud, LDAP is not normally the most appropriate solution, since it relies on setting up network access from a cloud service to a company's internal LDAP infrastructure. Therefore we are pleased to announce that in addition to LDAP, with Spira v6.4, we have added support for the Single Sign On (SSO) and delegated authorization protocol known as OAuth 2.0.
When you enable OAuth support in Spira, your users will be given a choice of logging in as normal with a Spira login and password, or using an external "provider" such as Google (illustrated below).
When the user logs in with the external provider, they will be redirected to a web page belonging to that system (in this example below we show okta):
Once the user has logged in with the external OAuth provider, if it is the first time, they will be asked to either create a new (unapproved) Spira account, or link the login to an existing one:
If they already have linked their OAuth account to their Spira account they won't see this page, but instead would be immediately logged into Spira, and taken to their My Page as normal.
When we release SpiraTest, SpiraTeam, and SpiraPlan v6.4 next month, it will come with the following OAuth providers:
Once this initial set is released, we will be looking to add additional providers in future releases, possibly including Microsoft AzureAD and ADFS, depending on customer demand.
The administration interface in Spira lets administrators decide which external providers (if any) should be enabled:
In addition, you can mix and match all three authentication types in one installation:
So the user list administration pages in Spira have been modified to display exactly what type of user is in the system, the Ext. Login column will display the name of the OAuth provider or LDAP if the user is managed by an LDAP service such as ActiveDirectory.
The other major new enhancement in v6.4 is to update the Spira reports center dashboard to have a new, central release picker. Previously some of the reporting widgets (but not all) let you pick a release to filter the graph by, but it had to be done on a per-widget basis. In v6.4 we have introduced a new dashboard-wide release selection dropdown list. This selection will affect all of the reporting / graphing widgets simultaneously, and will make configuring the dashboard by release much easier.
This new central release selector means that we are now able to have additional filtering options on the widgets themselves. For example, the Testing Date Range Graphs can now be filtered by both test case type and/or release at the same time. The Incident Date Range Graphs previously could only be filtered by incident type, and not by release, this is now enhanced.
Finally, this change also lets you have more powerful reporting for the various summary graphs. Previously you could not graph test case execution status against another field (e..g. priority) and have the results filtered by release. That is now possible for the first time.