SSO Auto-Provision

[Former Community Member]

Hi all, We implemented SSO last year for our department. We would now like to enable the Auto-Provision feature to allow greater access to Workfront for requests. Has anyone experienced any issues enabling the Auto-Provision feature following the roll out of SSO? SSO is working smoothly for us and we want to mitigate any potential impacts to exiting users. Please let me know if you have any lessons learned or best practices for Auto-Provision users. Thank you! TRINITE BRYANT Marriott Digital PMO

[EricLu2]

Oh, I'm looking forward to the responses on this one. If you search the community, you'll find it has been a topic of discussion in the past. I don't think anyone has asked how to transition to using it, however. Neat stuff! Eric

[MariusUz]

Hi everyone, so we've setup SSO directly to auto-provision users with some data from the Active Directory. The MOST important thing to note is that every attribute you are going to map is checked and updated every time as soon as a person logs in via SSO. This means, you should never map access levels ;). Apart from that, we are currently mapping: first name, last name and e-mail; which generally does not change when a user logs in repeatedly via SSO. In addition, we've set a standard value for the "Company" attribute, for each user which logs in via SSO - although this value is not provided via SSO! Good luck! Best, Marius Marius Uzolas HERE

[AmandaLe1]

We are in the process of trying to set up auto provisioning for one of our groups within WF. We've had SSO for over a year with no issues, but as soon as we set up auto provisioning we had a slew of issues - duplicate user accounts, names being changed to email addresses, etc etc. We are working with our IT department and WF custom service to try and figure this out and get it set up. I can report back with any learnings! @Anna Dreyser Amanda Levine Liberty Mutual Insurance Company

[DaleWh1]

We turned on Auto Provisioning about 6 months ago. We currently map First and Last Name, Email, Company, Title, and phone extension. We tried Supervisor, Access Level, and Groups, but the work to modify the AD and Ping challenged the IT organization and we are currently regrouping on that. Keep in mind that some of these fields (phone extension for instance) have limits on size, so if you map a field that is too big, it will break. The key for success is three-fold: Setup a request queue for your new users to request access. In that request, make sure the custom form asks all the questions that you are not able to capture through the SSO gateway or important information that will support any governance you have. I would also suggest you build the form to support account changes so that there is one user management form. Regardless of the approach, remember to share the form with either the default group (below) or everyone; whichever is applicable. And if you have multiple admins, this is the time to build out the queue topics to route the request to the right admin. When a new user is created, it defaults the account into the first group alphabetically in the system. Create a new group (such as 1Autoprovision) that will help find those people. If you don't want to share the one user management form/request queue with everyone, share the project with this first ranking group and then it will disappear once you complete the provisioning process. Best practice: Do not leave people in this group. You will invariably need to update at least one item on the record of the user and this is a great way to distinguish those that have from those that haven't. When a user is deactivated, auto-provisioning will no longer work for that user. They will get an error and a login screen. Build a communications plan and a process to triage these exceptions. As with any feature implementation, communications are absolutely required. Telling people to go to a website to have their account created automatically and then submit a request is not as easy as it sounds. So, a simple communications plan will go a long way. Finally, reports are your friend for this. You will need a dashboard that tracks open requests, tracks people in this temporary holding group, and deactivated users. This will help you troubleshoot failures, and maintain a level of service and continuity with the Workfront offering. Dale Whitchurch Arthrex Inc

[melindal3825541]

Here are my notes: Workfront considers the host SSO system to have the correct information. If information is maintained in both systems, the SSO system will always overwrite Workfront information on every log-in. To prevent needing to set up all of users' groups and access levels you can set up your groups and access levels so that the first alphabetically becomes the default. For access levels this is the first REQUEST access level that in your list. This listing doesn't seem to update right away. So set up these groups/access levels at least a day before doing testing. For groups it's the first public group (not subgroup). All Requestors, All Employees should be good names, make sure everything else is later alphabetically. Make sure this group defaults to a very simple layout template for requesters. You do not want the first impression of Workfront to be overwhelming. 1 request queues that should exist is -> Request More Access with an option on, where did all of my Workfront information go. This is for any user that accidentally gets a new account created. First Name is another tricky field. There are 4-5 common codings for first name, like First Name, firstname, givenname, name. If your mapping isn't correct, the first name is likely to be filled in with the username, which is often a mix of alphanumeric characters. Like mlay0001 or h100120 and most people don't respond well to that :) If you see this happen have the access administrator check exactly what field is being sent to Workfront. Less is more with mappings. If possible only map first name, last name, email address and leave everything else as defaults. Each new mapped field increases the possibilities for errors. If however you have access to a good, accurate directory, map away! But remember everything mapped overwrites everything in Workfront. Since first name is required this removes any nicknames! When auto provisioning is on, users that have a misspelling or other error in their user ID will have a new account created. It may even happen with capitalization changes. If an existing user suddenly gets a blank/reset account; check for a duplicate account! This is one case you will want to delete the new account and fix the user id in the old account. Log in as can be misleading here as you might be looking at a different accounts. This is a great time to use zoom and verify! Admin exemption should be maintained for at least one administrator and probably a backup! Things happen with SSO and someone needs to be able to fix any settings if a certificate accidentally expires or SSO error occurs. Remember that if user can't log in to the system, verify if they can log into other SSO systems before assuming its a Workfront problem. Once SSO is on, the domain.my.workfront.com URL will resolve to the SSO system. domain.my.workfront.com/login will provide backdoor access for those with the admin exemption or specifically excluded from SSO such as vendors. -- Melinda Layten, Senior Consultant Work Management Improvement CapabilitySource - 2018 Workfront Services Partner of the Year Phone: (484) 505-6855 site: www.capabilitysource.com email: melinda.layten@capabilitysource.com - we simplify your work so you can run your business -

[Doug_Den_Hoed__AtAppStore]

Melinda, thanks for sharing your SSO notes. Definitely in my save-until-needed vault! Regards, Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

[SaraEl]

Thank you all for the feedback! It is already helping us avoid/prevent issues. Thanks for taking the time to respond. SARA ROTHKOPF Marriott International

[NRYNR]

Hi Trinite, Auto-Provision and SSO for us turned out to be a real pain after some testing. One of the biggest issues was that we wanted users to start off with a "default" access level of "Reviewer". However, the ability to specify a default access level in Setup was taken out of the application, so this access level seemed to be picking the first one it could find in the list. Also, the fact that users were reconfigured to match these settings each time they authenticated turned out to be a huge challenge to overcome. We decided to automate via the API instead since it gave us way more control. In our instance, authentication succeeds when a user obtains the "Workfront Users" active directory group. What we do is query active directory daily and find users who have the AD group in their profile and add them to Workfront via the API. We prefer this approach because it allows us to: Be very specific in the user's profile configuration. (First, Last, Email, SSOID, Layout Template, Default "Reviewer" Home Group, Default "Reviewer" Access Level, custom data, manager ID, etc. Post an "Update" to the user's profile with a "Welcome to Workfront at SunTrust" notification. This up-front communication has proven very helpful. We provide some basic info, links, contact info, etc. This requires a pretty basic active directory query to identify users to add (and deactivate if applicable). It'll also allow us to get even more specific in the future if we decide to add more AD Groups. After that, we accept "Access Modification" requests. Here's how that looks: Narayan Raum Workfront CoE Manager & Delivery Lead SunTrust Bank

[JillAc]

Hi I found this thread that was very helpful but I have one other question. Because we use SSO, the account in Workfront is created after 2 things happen: the "link" to the new user is created by our IT so WF recognizes their authentication, and then after the new user logs in to WF for the first time. However, I would like to be able to copy an existing user's profile for new people so that I don't miss something as I go through the options. I can't figure out how to make that happen without creating a duplicate account. Advice? Thanks, Jill Jill Ackerman

[AdinaPi1]

I go to the people tab, select the user I want to duplicate, and pick the New from Selected Person option. Then I just need to add the first name, last name, email, federation id, uncheck the ' Send an invite email to this person' box, and check the 'Only Allow SAML 2.0 Authentication' box then they are set. All the other fields like job role, team, custom forms, etc are already there.

[JillAc]

Thank Adena. Every time I do what you say I get a duplicate account created when the person logs into WF. I think it has to do with upper and lower case in the email address, or possibly in the name fields. After I had 20 duplicate accounts and had to start all over I didn't test it further. I suppose I can try this again the next time I have a new user, and ask IT to supply me the exact format they used to create the master ID that WF references. Have you had that problem or is the nomenclature in your company so consistent that it isn't an issue? Jill Ackerman | Director, Product Marketing Lindblad Expeditions 96 Morton Street | New York, NY 10014 Ph. 212.261.9080 | Fax. 212.265-3770 jilla@expeditions.com | "http://www.expeditions.com/"> www.expeditions.com

[randyr6740755]

Use the federated ID, and it is case sensitive. It should be FirstLast no spaces. Get the case right and it should log you in with no duplicate. I would just delete the dupes so you can start fresh. Randy Roberts Zimmerman Advertising LLC