June 18, 2015 Leave a comment
With the release of 6.2, customers will have the option to login to frevvo via SAML 2.0. This is primarily meant for cloud tenants who use LDAP but do not want to expose it over the internet. Of course, there will be those who prefer to use it simply because it offers single sign-on (SSO). The inability to access LDAP does require us to store user and role information in frevvo in order to route the workflow tasks. This data duplication may seem unwarranted in on-premise deployments, where LDAP is accessible. On the other hand, there is still Integrated Windows Authentication as an SSO option.
The use of SAML requires the configuration and installation of a SAML identity provider product. These products can be free (Shibboleth, OpenSSO) or commercial (ADFS, PingFederate, etc), require IT savvy personnel to set it up, or be subscription based cloud providers like OneLogin who provide connectors to hook up your LDAP with SAML. Once setup, you need to release attributes about the user viz. user id, first name, last name, email, manager user id, and role names. Manager and Role attribute values are typically available as distinguished names (DN) in the LDAP, and require additional lookup and transformation to convert them to identifiers. The support for/ease of doing this varies depending on the LDAP and SAML product. Other custom attributes can also be released for use in frevvo forms. In addition, the ‘frevvo.User’ role must be configured for any user to be authorized to access frevvo. The Add/Edit Tenant screens allow configuring the service and identity provider metadata as well as mapping the attribute names. Security in SAML is achieved via signing/encrypting the communication and this requires managing cryptographic keys. This can be setup in the key-store provided with frevvo.
While the user attributes can be discovered and saved on login, routing to other users requires user/role information to be available upfront. This can be accomplished using the bulk user CSV upload feature that is already available for use with the default security manager. Custom attributes, however, will not be persisted. With user information coming from 2 sources viz. login and upload, the most recent data will be used. Complete information needs to be provided from either source as there is no support for merging data.