SSO Pain Points

[JodiBi1]

We are considering implementing SSO. What pain points did you experience with your implementation? Seeking advice for things to consider. Thank you! Jodi Biscevic GMF, International Operations

[AnthonyPernice]

I'm not aware of the technical details of SSO, but as a WF admin it's been great for the most part. Password management is one less thing for me to do for my users, though initial implementation was tough at times, mostly due to user error. Our SSO software sometimes messes up or Workfront changes something that we didn't properly prepare for, but it's mostly smooth. From the user standpoint, it needs to be made clear that ONLY the SSO portal will allow them access. Lots of users would log out and then try to log back in using the Workfront login page, so be sure to hammer that point home. Anthony Pernice Healthcare Consultancy Group

[SkyeHa]

We have the following as "pain" points -- they are not that painful; more things to note. 1) The work my team does in Workfront is considered business critical, so during the once a year that SSO goes down, there is a mad scramble for people to remember passwords and such. As a related note, I think the password reset feature might be defective because I've heard comments from my users in the past that they have requested auto-password reset and not received a new password. I usually reset any passwords that need to be reset. 2) We do a lot of testing and training in the Preview environment and this was not able to have SSO for some reason (I don't remember why, but it either has to do with additional cost on our end, or with the fact that it is refreshed every week). As a result, we still have to set a password for everyone when we create their account in our production environment--even though they technically don't need it there, they will need it for Preview or in the unlikely event of SSO outage. -skye

[cwatson]

We began using SSO four months ago. The biggest pain point was getting the system set up properly in conjunction with our IT department - white listing the right IP addresses, etc. Switching over to SSO was very simple and our team has been fine with it. The pain points since making the switch are: people getting locked out of Workfront and their other corporate systems because of repeated incorrect logins - eventually the corporate account locks and users can't change their passwords and need IT to unlock it. That's not specific to Workfront but incorrect logins there contribute. Workfront had a major technical issue a few weeks ago that killed SSO login for us and other customers. We turned off SSO and went back to the Workfront-specific login process so people could get access (we needed Workfront support to batch disable SSO for everyone's account) until it could get corrected. It took longer than expected because Workfront moved our accounts to a new server with a different IP that hadn't been whitelisted in our systems here. Overall, SSO has been a pretty seamless process and our IT department is very happy we're using it for system security purposes. Chris Watson KVH Industries, Inc.

[FrancesDurhamEvans]

Implementation was a challenge for us but the issues were on our end and not Workfront's end. Our IT department had some things to work through due to the way our particular internal firewalls are set up but they were able to figure it out along with the help of Workfront Support. Once set up, SSO has been working out for us just fine and we are happy we did it. Frances Durham Evans Famous Footwear

[EXP_-_DustinMa]

Hey Skye, We recently (Novemberish) changed how we handle the SSO table in Preview, it no longer gets wiped out each refresh. Same for those companies that have a SB01 or SB02 environment (a custom refreshable sandbox). You can now set up SSO for Preview (usually used for testing or for companies that tend to do a lot of configuration changes quite frequently) and it will retain the data each time it's refreshed. Back to the main question, the typical pain points I hear are when setting up SAML 1.1 or 2.0. The setup process requires a Workfront system admin, as well as someone that is knowledgeable about their SSO provider, though I'll say things have been getting a lot easier with systems such as Okta and PingOne. Reach out to support if you have questions, or peruse our help center for various articles with the different types of SSO. Happy holidays to everyone, and Merry Christmas to those that celebrate! Dustin Martin Tier 2 Assigned Support Engineer Workfront

[MeredithLa2]

We had a couple of issues using SSO; one resolved, the other still an irritation Auto-provisioning users with alternative access level - base on our use case we needed users auto-provisioned at the "reviewer" access, as opposed to the default "requestor". It took a handful of contacts @ Workfront to get the right expertise - but we were able to get rules in the setup area and adjustments to our active directory in place to make it happen. Links to work objects from email notifications not working - when users receive email notifications from Workfront, if their session has expired and they click on a link to a Workfront work object, they're first taken to the SSO page, then redirected to their landing page instead of the work object. For more frequent Workfront users this is more an irritation than a problem. But for seldom users, this creates much confusion and the perception formed is that the system "isn't working". Workfront has told us that it's got something to do with our firewall or Exchange server settings. Our IT department (who does not support the application) is dismissive. Now that we've been live for 6 months and usage is growing rapidly, we need to get serious about finding a solution to improve user experience. Anyone else experiencing something similar? Any advice? Meredith Landsmann PMP Analog Devices, Inc.

[EricLu2]

Hi: I would be fascinated to know how to auto-provision to a particular type of license. We aren't auto-provisioning because we wanted to control what kind of license they end up with and back in the day, no one knew how to do that. Do tell! Thanks, Eric

[SusanPf]

Hi, Eric. Requester is the default and can't be changed. Thanks, Susan Susan

[DavidTa1]

Eric, In order to automatically assign a different access level than Requestor you need to identify what Active Directory field you can use to determine what license the person receives. I have had clients use a team or group field in active directory, and I have had them use a title field. It doesn't matter which Active Directory field you use as long as it is not a text field (hard to map if they can put anything in the field). Once you do this, active directory will control what access level everyone receives and you will need to map all access levels. Also, with auto-provisioning turned on, it will verify based on the mapping every time someone logs in which is why, if you change their access level in Workfront, it will revert back the next time they log in. I hope this helps!! Let me know if you would like to talk more about it. David David Taylor - moventus Moventus

[EricLu2]

Yikes. Way to crush my hopes in eight words �� Maybe someday... Thanks, Eric

[JillAc]

We had a few: 1. You can't use the Welcome notification in Workfront as it has users login directly and not through the SSO. I didn't know that and had to delete everyone and give them new instructions with a link to SSO. It also means I couldn't upload the staff info first (maybe you can, I couldn't figure out how to make that work together0. It also screwed up the ProofHQ logins as when I manually added the users the first time and had to delete them, they were only deleted from Workfront and not from ProofHQ and it ran out of licenses so when people started signing in via the SSO they didn't get a Proof license. Workfront fixed it for me, took a couple days. 2. The people who were setting up the system before the SSO was implemented had some trouble converting their accounts to the SSO sign in because the Federation ID is case senstitive and it didn't match. It was an easy fix once we figured out why it wasn't working. Jill Ackerman Lindblad Expeditions