The answer is Yes.
PPO currently supports single sign-on through Security Assertion Mark-up Language (SAML).
SAML is an internet standard, XML-based protocol that has been widely adopted by major software vendors including SAP, Microsoft, IBM and Oracle. These vendor products typically act in the role of identity providers, service providers, middleware and discovery services. SAML is used to securely exchange user information between service providers (SP) and identity providers (IdP), typically for log on and log off operations.
SAML support enables us to implement a single sign-on mechanism that will allow our clients to authenticate against their enterprise or other systems (such as Active Directory, Facebook, Twitter or other similar applications), instead of using our normal PPO security. This gives their network administrators better control over the administration of their resource pool, as well as the added peace of mind that user identities are maintained from within their enterprise.
How does it work?
PPO uses the service provider initiated log-in pattern. The diagram below illustrates the flow of information during the process.
- A user makes a page request to PPO. PPO discovers that the user is not authenticated and initiates the SSO process.
- PPO responds to the user’s browser with a hidden form containing an authentication request to be forwarded to the IdP.
- The user’s browser then automatically posts the hidden form containing the authentication request to the identity provider’s publically available endpoint.
- The identity provider receives the authentication request and proceeds if it is satisfied that it originates from a trusted source. The mechanism for determining the user’s identity could differ from one IdP to the next. Typically the user will receive a log-on form as response.
- Once authenticated, the identity provider replies to the browser with an authentication response.
- The browser automatically posts the authentication response back to PPO. PPO passes the response received. The identity contained within the assertion in the response is used to identify the user in PPO and establish a session.
- PPO responds with the page that was originally requested by the user.
All traffic is encrypted and communication between the browser and PPO is secure over HTTPS.
How do I go about setting this up?
The process of setting up single sign-on for PPO will be facilitated by the PPO Support Team. If a client wants to set up single sign-on, please submit a request with the PPO Support Team to start off the process. The process facilitated by the Support Team will follow this simple, two-step route:
Step 1: Set up a trust relationship
Before any integration can take place between PPO and an identity provider, a trust relationship is configured between both parties. A public key for PPO’s certificate is supplied to the identity provider along with XML metadata that describes how users will be authenticated.
Important information included in the metadata is the KeyDescriptor (contains the public key of the service provider’s certificate), the NameIDFormat (indicates what name identifier format the service supports) and the AssertionConsumerService Location (the pre-arranged endpoint of the service provider’s service).
Step 2: Configuration
PPO supports two security modes - Default and SAML. In order to activate the SAML security mode for a PPO instance, the endpoints to the identity provider need to be configured in the instance's system configuration.
Step 3: Cross-site authentication
For the SAML security mode, access is not allowed to the normal PPO login page (login.aspx). For cross-site authentication purposes, an alternative log-on page has been created, that excludes the ‘forgot password’ feature (xsite.aspx).
What can users expect?
There are a number of changes that a user can expect when a PPO instance is configured for SAML authentication.
When a user makes a request to a PPO page via their browser and is unauthenticated, the default log-in mechanism will be replaced with an alternative mechanism, usually in the form of a log-on page similar to that of PPO.
Some users belonging to large enterprises and federated systems might use their normal way of authentication like for their other systems they are already accustomed to.
Accessing the default login page (login.aspx) is not allowed. Users are rather redirected to their home page. This will also be the case for users that have previously bookmarked this page.
The default behaviour for the Log Out button on the PPO menu bar is to clear the user’s session and to redirect to the login page.
With SAML authentication configured, the user’s session is still cleared, but the user is directed to the IdP portal as well where further clean-up procedures could be required.
No More Passwords
Seeing that log on credentials are being maintained by the identity provider, there is no need to do so in PPO. Password related functionality that is disabled includes:
- The exclusion of temporary passwords from welcome emails
- The ability to reset user’s passwords
- The ability for a user to change their own password
SOAP web service integration
Seeing that SAML is browser based, this authentication scheme cannot be used when consuming PPO’s SOAP web service, as it requires a user to supply credentials through a web browser and integration is usually performed by back-end processes.
Authentication is however still possible with PPO’s default authentication scheme and a user account specifically configured for this purpose. Assistance is required from the PPO technical team to set this up as it requires switching between authentication schemes with some downtime as a result. This could be disruptive to active users and coordination between the customer and PPO support staff is therefore essential.
Please contact the PPO Support team if you require assistance with this.
Microsoft Project Add-In
SAML is constrained to web browsers accessing web-based applications such as PPO since it relies on a mechanism of redirects to allow the user to authenticate against the Identity Provider.
The SAML standard also does not enforce any particular authentication mechanism, so the Identity Provider is free to implement any of a variety of mechanisms such as forms based authentication, Windows integrated security or token based authentication.
What this means is that it is not possible for a non-web based application such as the MSP Add-In to implement SAML authentication in the normal way and therefore the add-in currently does not work on PPO instances that use Single-Sign-On.
The industry has recognised this problem and various efforts are currently under way to allow SAML to work seamlessly on all platforms. Some possible solutions include using a combination of OAuth and SAML as well as using SAML back-channel communication. We are carefully watching progress in this area and will consider implementing a solution for the add-in as soon as we believe that a workable solution is available.
The work-around used for calling SOAP web-services is not practical in this case since it would require users to maintain dual identities (a SAML identity as well as a PPO identity) which would defeat the purpose of single-sign-on.
For more information on single sign-on please read through the attached document, or to request single sign-on to be set up for your instance of PPO, please submit a request to the PPO Support Team.