Flinders University has overhauled its identity management, allowing students to accept study offers and provision the software applications they need in under a minute.
Chief information security officer Aaron Finnis told last month’s Oktane18 conference that the Adelaide-based university wanted to remove roadblocks to a student starting their studies.
It similarly wanted to make it easier to onboard a new staff member or an externally-based “affiliate”.
The university has a shade over 60,000 users on its IT systems in any given year, and “commences” about 6000 students every year.
The goal of any commencement process is a simple proposition: “we want our students to commence as quickly as possible so they could accept an offer with us”, Finnis said.
“Students are bright and get a lot of offers. We want them to accept the one at Flinders and there’s a monetary value in that,” he said.
“Any barriers to that, any friction or issues along the way, hampers that first impression that they have of us.”
Students were initially presented with a course offer from the university’s tertiary admissions centre. The offer contained a webform they had to submit in order to receive a personalised ‘five steps to Flinders’ email.
“We nicknamed this internally ‘87 steps to Flinders’ [because] each step had multiple sub-steps to it, so the detail that was in there was kind of ridiculous,” Finnis said.
“We should have almost handed out degrees based on if you could navigate your way through this.”
Setting up the student’s identity credentials was buried in step two of the process.
The university calls its user ID credential the Flinders Authentication Name or FAN. This was mailed to the new student with another package of information.
Using it for the first time was complex.
“To activate your account, you had to combine that user ID that you just got with the initial password, which was [created by] merging of a bunch of data that you had to put together,” Finnis said.
That combination of data included the day’s date in Australian format.
“For international students that didn’t work well,” Finnis said.
The entire commencement process took anywhere from 20 to 40 minutes.
“Students were hit with so much information to start with that they were just overwhelmed,” Finnis said.
“As a result, they were hitting our service desk and support teams pretty quickly.
“We knew that process had to be rethought from the ground up.”
The university set a goal to cut the process from up to 40 minutes to “around sub-four minutes” in the first instance.
“We could do better probably but that was a starting point for us,” Finnis said.
Flinders also wanted to be able to use role-based information on new activations - whether student, staff or affiliate - to determine which IT applications they would each need, and to automatically provision them.
This would ideally occur as soon as the new user set up their password, Finnis said.
Bringing identity upfront
The university launched a transformed activation system and process in time for the first semester of 2017.
The system is built around bringing identity to the forefront of activation, making it simpler for the university to “know upfront who we are dealing with”.
Solution architect for identity and access Jan-Marie Davies said that for the purpose of activation, users are provisioned into an identity vault - based on NetIQ - “where we do some matching, generate an authentication name and then we send those users into Okta” via an API.
The matching is with data held in the university’s “three sources of truth for identity data” - its student information system, HR system and an affiliate management system called Access Now - where the identity record is initially created.
This is a “simplified version” of the architecture; both Finnis and Davies said there was some room for improvement.
For example, Finnis said IT had a “goal overall … to get rid of the vault.”
“It’s a bit of technology that we don’t want to maintain. It’s on-premises as well, it doesn’t really fit with our [desire to move IT to a] cloud delivery model,” he said.
“So if Okta can do the work in a more modern and flexible manner then we’ll use that tool for [that function, too].”
Currently, Okta is set up to manage all the different roles and permissions attached to each.
For students, the different roles might include applicants, offered students, PhD students, research, international, honorary degree and higher degree.
Staff user types include faculty, casuals, academic status holders, professors that come in to guest speak, administrative staff and professional staff.
The third type of user is an “affiliate or external”, often requiring only temporary access. This could include IT vendor representatives, agency contractors and visiting high school students.
“They might be there from one day to two weeks and we can easily generate them an account on the fly,” Davies said.
Different roles may have different security requirements, and these are reflected in the activation process.
“As we implement more granular roles, and those roles then also translate into security policy, we might have more significant password strength requirements on one role over another,” Finnis said.
“With our entire security architecture is built around identity, we can now implement those [requirements] with confidence.”
Under a minute
Davies said that the university has now slimmed the student activation process to under 60 seconds.
“We worked with the tertiary admissions centre to personalise an email with less information that went out to our students with their offer,” she said.
“In that email was some really basic instructions about what they needed to do to activate their account, and where they needed to go once they activated their account to check their courses, topics and enrolment status.”
Now, students are simply presented with a link to an activation landing page, “which is an application we built internally so we could customise the content to the different cohorts of users that we have,” Davies said.
“From there, they click on an activation button, which is an activation link generated by the Okta user’s API that takes them straight through to their account setup where they put in their security information and hopefully reset their self-service password.
“And then that takes the student straight through to their Okta dashboard.”
The Okta-based dashboard then shows the user a page of icons for all the applications they will need, such as student systems, Office 365 and online payments.
“The dashboards are customised for our particular cohorts of users,” Davies said.
The staff activation process is slightly different, with the initial identity record set up in the HR system from which a link to the activation page is sent via SMS.
This could be streamlined in future as the university works on a separate project to replace its HR and payroll systems.
Once that occurs, “we can have a more advanced process and send them straight through to Okta” rather than via a separate page, Davies said.
“We’re working on that this year, which will be very exciting. Even so, it’s a really quick process for new staff. They can do it all on a mobile.”
Students activations double
Finnis said that almost double the number of students accepted offers and activated accounts with the university on the first day.
“On that first day, we went from 712 activations in 2016 to 1530,” he said.
“That’s quite a significant increase and it evened out after that as we normally expect until orientation week.”
The university also saw “about 2600 less support calls” to its student support centre for the 2017 intake, and 468 less support cases raised.
“In addition, the really basic questions - how do I get started, what’s a FAN - started disappearing from conversations, and we started to only get more difficult questions,” Finnis said.
The activation process became invisible to students, something they did not even have to think about.
For Finnis, that meant the project had achieved its goal.
“As a result, after talking to a number of students about that process and how annoying it was to commence, we wanted them to walk away from the new process not really thinking too much about it,” he said.
“We wanted it to be familiar, similar to how you sign up to any online service, or even better if we can make it better.”
Buying in more SaaS apps
Moving to a single sign-on model for accessing enterprise applications has also forced the university to change up its thinking.
The university had 10 apps SSO-enabled at launch for semester one in 2017.
“We’ve got 80 apps on Okta now and we’re continuing to provision more, probably at a rate of one or two every couple of weeks,” Finnis said.
“We learned a lot through this process. One of the big things for us at Flinders is we’re pushing very heavily into cloud hosting and SaaS-based products primarily.
“So every app that we’re buying from this point on, we’re checking to see if it has SAML or OpenID [federated identity open standard support].
“We’re pushing vendors quite hard if they don’t have that integration.”
While most modern apps supported open standards for federated identity, Finnis noted that “some app vendors - particularly in education - probably haven’t been asked about that kind of functionality” before.
“We’re really working with our vendors closely to make sure we have that integration ready to go,” he said.
Okta also has a library of around 5500 pre-built integrations with enterprise services and products - called the integration network - that the university has been able to lean on.
“Anything that is in the Okta integration network is great, and that’s probably the first question we do ask when we’re procuring apps as well, is making sure they’re in the network so we can start to use them [with SSO] straight away,” Finnis added.
