Single sign-on (SSO)

Public

What is Single sign-on?

Single sign-on (SSO) is a secure way to link two separate systems so that users of those systems do not have to remember another set of credentials. Users would typically log into computer systems at their place of work and when they need to use the PageUp web application, they can click through into PageUp without having to remember another set of usernames and passwords.

Using single sign-on in conjunction with a user-feed integration into PageUp is strongly recommended. This means that when users or network administrators update user credentials on their corporate network, those updates flow through to PageUp and single sign-on is secure and seamless. Information about data integration is available in the document HRIS Standard User Specification. Contact PageUp for this information.

Technical Information

The method below is listed because it is commonly used by other organisations.

If your organisation's preferred option is not displayed below, it may still be supported, so please talk to your PageUp account representative.

Client operated SAML service (recommended)

Using this method, when a user attempts to access the PageUp web application, a SAML request will be sent back to your organisation's identity provider (for example Active Directory), where the user is authenticated and a signed single sign-on token is generated and sent back to the PageUp web application.
For more information refer to the relevant SAML technical document.

This option is commonly utilised by organisations that have strong technical representation, (and often use Active Directory Federation Services (ADFS) to authenticate users), to maintain a consistent approach with other applications. If this method is chosen, your organisation's technical team is the first technical point of contact when issues arise with single sign-on.

How does my organisation go about setting up single sign-on?

Your PageUp account representative will organise an initial meeting to discuss the options for single sign-on, alignment with either a new or existing user-feed integration and to establish the next steps. Both Project and Technical representatives from PageUp will attend this meeting. Representative(s) from your project team will be required to attend, and one or more technical representative(s) will also be required.
PageUp has provided the following technical documentation for each of the supported methods for single sign-on:

You may wish to provide these links to your technical representative prior to this meeting to give them a background of the supported options.

Prerequisites

Regardless of which of the above methods is used to facilitate single sign-on, it's necessary for the user who is attempting to sign-on to already exist as a user within the PageUp system.

The chosen single sign-on mechanism will pass through a unique user identifier to PageUp when the single sign-on process occurs. This identifier is then used by PageUp to look up the user within the database to identify the appropriate user account, and that account is then used to sign-in to the system.

Users can either be manually created by a Superuser within the PageUp administration interface, although depending on the volume of users, this may not be practical, and many clients choose to manage user accounts by way of an automated daily feed of users.

Some clients may already have an existing integration in place with PageUp, and provided that integration includes a feed of user accounts, minimal amendments are usually required to that feed to facilitate single sign-on.

If a new integration file is required, this will need to be sent to PageUp on a daily basis via secure FTP (sFTP). Your PageUp representative will be able to assist you with obtaining the correct credentials for the sFTP account.

The file needs to be a simple delimited text file, which contains a row for each active system user.

The file should contain the following data elements:

  • UserID - unique identifier - usually employee ID from HRIS
  • Title
  • FirstName
  • PreferredName
  • LastName
  • Email
  • Secondary ID - optional - may be required if a different ID is passed by the SSO mechanism

If an existing user leaves the organisation, they should be removed from the daily user feed file, and this will result in them being automatically archived from the Page system.

Enabling or disabling SSO

If value changes are made to the System settings feature: Authenticate with SAML (bAuthenticateWithSAML), any changes will take up to 5 minutes to be reflected on the Auth Service.

Frequently Asked Questions

Is it possible to have single sign-on users coming through in data integration, and also have manually created users?
Yes. All users coming through a data integration into PageUp will use single sign-on. Manually created users who are not included in the integration cannot single sign-on, and must login using their email address and a password set up for them by a system administrator.
Note: the integration will not update any details for manually created users, and any changes will have to be made by System administrators.

When a user already exists in PageUp, how does the data integration know which user to update?
Each client has differing requirements for updating existing users through the integration, however, most clients match users on a unique employee number assigned to each user.
Alternatively, it's possible to match users by email address if required (however all users must be included in the integration, and you cannot have manually created users if this is the case).

When moving from manual login to data integration with single sign-on, can all users continue to use the system?
Yes. There is no technical reason why you need to lock your users out of the system when implementing single sign-on with data integration. Once the user details are updated by the integration, they will start to login to PageUp via single sign-on automatically.

What infrastructure exceptions do I need to make to support SSO requests?
Firewall communication paths will need to be opened to allow traffic from a URL below, which will depend on the location of the datacentre you will be hosted out of.

Australia - *.dc2.pageuppeople.com
Europe - *.dc3.pageuppeople.com
Americas - *.dc4.pageuppeople.com
Asia - *.dc5.pageuppeople.com

What is the new Should Check SSO Expiry Date Feature Flag and why is it important for my organisation to activate it?
This feature flag validates the expiry date of your SSO certificate/s.

If the flag is set to TRUE, the system will monitor the expiry date of SSO certificates. Beyond the expiry date of SSO certificates, users who access your organisation's PageUp web application will be notified and will be safely prohibited from access.

However, if this flag is set to TRUE and your certificate expires or is expired, no user will be able to login to your organisation's PageUp web application. Given this, it is highly recommended that you proactively renew your SSO certificate before its expiry to avoid users from experiencing this.

If the flag is set to FALSE, there will be no monitoring of expiry dates and users will be able to access your organisation's PageUp web application even beyond SSO expiry.

Troubleshooting

Why can't a user login via SSO?

The most common issues after clicking the Intranet PageUp link are:

  • The PageUp Admin login screen loads instead of the Dashboard.
  • The user gets the error message: Invalid User. Your attempt to login to PageUp has been unsuccessful.
  • The user gets the error message: Authentication failed. Token expired.
  • The user gets the message: The Page cannot be displayed.
  • The user is prompted that the SSO certificate is expired.

To confirm it's an SSO issue, get the user to login via Admin, for example, admin.dc2.pageuppeople.com
Note: SSO users may not be aware of their password so it may need resetting. This won't affect their SSO login credentials.

Check the setup of the user's account:

  • ensure that the user's account is not archived
  • login access is set to Yes
  • an ID number (sBadgeID) eg 310484
  • an Employee number (sProviderNo) eg ABCD
    Note: The labels of the last 2 may vary and your system may only have one. If incorrect this may be the cause

If the user's account is configured correctly, get them to clear the browser's cache.

Comments

0 comments

Article is closed for comments.