Customer Story: George Washington University

[UPBEAT MUSIC PLAYING] Good afternoon, everyone, and welcome to Invite-- I'm sorry, Unite Miami-- Invite, Unite-- and our journey to IGA. My name is Chuck Mance. I'm the Manager of Identity and Access Management for the George Washington University. I've been in the IT space since around 1973, so I've been around the block a little bit. Sheema? Hi, I'm Sheema Begum, Senior Identity and Access Management Developer at the George Washington University, and I have been in this space for more than a decade now. Thank you, Sheema. What we're going to do over our next 30 minutes, we're going to walk you through our journey. We're going to talk a little bit about introducing our university, introduce our team, what they do, and some of the services they provide, talk about the challenges that we had that led us down this path and how we started the process. Then Sheema is going to take over and talk about the methodology we used to select the vendor, the rollout, the deployment, some of the challenges we had, some of the benefit we realized, and where we are today. And then, I'll close out the session with what the future looks like. One of the cool things about coming to an event like this is the ability to meet new people, to network, to collaborate. So as you progress through the remainder of the week, you sit down at sessions, you have lunch, you sit down on meals, take a minute to introduce yourself. Introduce yourself, where you're from, and talk about the challenges you're having. By the end of the week, you'll probably find that your network has expanded maybe 15, 20 people, and you might have even made a couple of new friends. We actually have a colleague who met his wife at a conference, so you never know, right? [LAUGHS] So let the journey begin. George Washington University, founded in 1821. That's only 45 years after the founding of this great nation, so we've been around for a while. And there's a lot of history at the University. We are located in the Northwest sector of Washington, DC in the Foggy Bottom area. We have three campuses, the main one being the Foggy Bottom Campus. We have a small campus about two miles north of that, Mount Vernon, that houses some athletic fields, some resident housing, and some classroom space. We also have a large Science and Technology Campus in Ashburn, Virginia, about 25 miles west of Washington, DC. We are the third-largest property owner inside the District of Columbia after the local and federal government. In the last number I heard it, we owned around 160 properties in the Northwest. So we have a rather large footprint there. We're an NCAA Division I school. We have 20 sanctioned sports. We're an R1 division university. We'll talk a little bit more about that in a minute. Our students come from every state, commonwealth, district in the United States, and over 37, 36 countries. We manage over 200,000 identities. So when you think about complexity, University-- I came out of industry into the higher ed space, and I'm here to tell you that university identity is way more complex than anything you're dealing within industry. We have students, faculty, staff. We have alumni. We have guest contractors, visitors to the University. And as an R1 institution, we also sponsor a lot of research, so that we have researchers, principal investigators coming from all over the world to collaborate with our researchers. So the one thing that researchers need is access to data, right? So it's our job to keep that data safe, to keep our intellectual property, our digital assets safe. Our team, we're part of the overall GW IT department. We're about 250 people within IT. We're a small group of six or seven that reports into the Cybersecurity, Identity and Cyber Risk Team. So we're integrated with the security team. And some of the services that we offer, provision and deprovision, as you would expect, two-factor authentication, single sign-on, VPN management, Active Directory, Azure management, group management, password management, and we have Federated Identity. We use the in-common Shibboleth Federated Identity Framework. And in that model, we're an IDP. We're an Identity Provider. We're also an SP, a Service Provider. So we provide services to the Internet2 research community-- things like REDCap for our researchers. And we also broadcast the SSID called eduroam. So if you belong to the Federation, you travel across any university that belongs to the Internet2 community, you'll see EduRoam, and you can log in and sit on, and you're up and on their Wi-Fi without having to authenticate. And also, you had that ID at research hospitals-- Johns Hopkins, Cleveland Clinic, the Mayo Clinic, University of Pittsburgh Medical Center, those folks also broadcast that SSID. So we're all part of that federation. We can get in, log in, and we're up and on without any kind of authentication-- and any kind of additional authentication. When the journey begins, it's about 2018. We're running on Oracle Identity Manager. Those of you who work with Oracle over the years know that it can be a beast. It's resource-consuming-- not just technical resources, CPU, storage, those resources, but from a human capital perspective, it's also resource-intensive. Our team was pretty much spent most of their time just keeping this thing running and very little time to really address the business needs. So we were coming to the end of our maintenance and had to make the call whether to renew or to do something else. So we made the call to do something else. We had funding allocated, so we started leaning in that direction. And something happened, and we lost our funding. So we're standing with one foot in this camp and one foot in this camp, and what do we do? We reached out to our colleagues that Active Roles, the Quest team, and had a conversation about, how can we utilize that as an interim identity platform? We used the out-of-the-box functionality of ARS and built a custom rudimentary identity solution on top of that. And it's interesting, when we moved off of Oracle onto the Active Roles platform, it took about a week to do the transition, which you'd expect, and we ran for about two weeks before we got our first ticket. So it was a really, really nice, smooth transition. So credit to the team for all the hard work they've done, and our partners at ARS. So we made the call to move to ARS as an interim solution. Some of the drivers-- so we ran this for about 4 and 1/2 years, and we realized that it wasn't sustainable or scalable. And we were getting a lot of demand from the University for more identity services. We had challenges with cyber insurance, cybersecurity. We had a lot of different auditing, not just from an internal technology systems audit perspective, but from a financial audit perspective, attestation. Those two components were very manual processes-- pulling spreadsheets and putting them together, and providing that data. And the attestation process, I don't event want to mention what that was like, but it was painful. We know we need to do something with role-based access control. And Higher Ed is one of those verticals where you'll find people who have worked there 20, 30, 40, even 50 years. And oftentimes or not, they have all the access they collected over the years. So there was no deprovisioning, no moving them into the new space or the new access. So we know we need to do something with role-based access and control from a least privilege perspective. Cyber insurance, we were getting pressure from that as well. And we wanted to bring more applications under the IGA umbrella. I'll let Sheema walk through the process for going forward. So Sheema? Thank you, Chuck. So Chuck talked a little bit about how we started our journey towards an IGA platform. Before getting into how and why we selected One Identity, you might all be wondering, why would an university need a true IGA platform? Like any other organization, the first critical thing is to understand the user base and what access they need. So unlike other organization where the employees are either full-time, part-time, sometimes contractors, a university has faculty, students, student workers, student researchers, and alumni. And for alumni, we provide email for life. So their identity stays in the system for life, which is a big risk if the alumni user is not using it frequently. And sometimes, a staff decides to take-- enroll into a course and become student. Now we have a staff member who is also a student. So that specific identity needs an access like staff as well as student. And same thing, alumni sometimes come to teach, and they become alumni and faculty. So with this pool of identities to manage, an ever-growing list of applications to provision and maintain access in them or outside them, and during pandemic, we had to go to the distance learning model. So we had to bring and scale this access management to this number of applications on-prem, cloud. We were scrambling to scale that, to meet the distance learning demand during the pandemic. So ever-growing, ever-growing demand of applications that we have to onboard, and also keep our business-critical systems secure and safe, and also let our researchers have the platform where they could collaborate, and also keep their data secure. So that was a very challenging environment to support and continue. So we made a strategical plan of how we want to go to a true IGA platform. To sustain this, we needed a sustainable, safe, and scalable system. So what we did was we made a strategic plan, like how we want to go to an IGA platform-- a true IGA platform. So going to a true IGA platform is not like a few months or like a half a year thing. So we made a plan for how we want to be in two years, three years, and five years kind of scenario. So we looked at the Gartner Magic Quadrant for the IAM platforms, and we took the players in that-- SailPoint, Octa, Microsoft, One Identity, Bing, and Saviynt, all of those. We analyzed those. We wanted to see how they look. Do they meet our requirements? Checked out a little bit about our requirements, how we wanted [INAUDIBLE] for our applications and attestations-- attestation auditing. And we had a lot of regulatory compliances that we had to meet with, in addition to the demand that we were seeing. So we also attended Gartner Identity Summit, where we tried to understand what's the current trends, and also listen to the challenges and the solutions from our peers. We did that, and then we started interviewing multiple vendors and integrators. And many platforms also gave us a demo of the application how we could configure our business logic, our code, into those applications. So during those demos, we were paying very close attention to how we could integrate the code and maintain it, because coming out of Oracle Identity Manager, while I was working with Oracle Identity Manager, working with the code or integrating the code was not easy. So we took the demo from this one, and One Identity also did a demo for the product for us. And during the demo, we asked all the questions that we wanted to ask so we could understand the platform, how we are configuring it, how to configure it, and how to maintain the platform. Maintaining the platform is a very, very big aspect. OK, during the implementation and during the platform is being set up, you get help, or, you get a consulting thing and they come and set up. After that, you're on your own. You need to-- mostly, you need to understand the code and able to maintain it. So we were making sure that we were accounting for the maintenance aspect of the platform as well. And personally, when I looked at One Identity, the things that showed potential to me were it's the ease of configuration, how they were demoing it, and they were showing us how you could configure the code and also, if you cannot configure, how you can integrate a code if you write the code in VB, or PowerShell scripting, or another type of scripting. So looking at all that, and also, we looked at the list of connectors that One Identity was giving out of the box, both for on-prem applications, and also for the cloud applications. Like earlier, when we were using Active Roles as our identity platform, there was no out-of-the-box connectors, so we didn't have visibility into the data we were provisioning. But we were not able to see what's in the target system-- like is there any additional access? Is somebody else giving any extra or additional access as a backdoor approach in the target system? So we were also very keen on what are the out-of-the box connectors. So those were the factors that we were looking during that discovery phase, and then we created cost versus benefit matrix. And we compared all the different IGA platforms that we were researching and evaluating to make sure that the platform that we pick satisfies or meets our requirement, our budget, and is also easy to maintain. So during this analysis, we thought One Identity was meeting our requirements and was also very configurable and easy to maintain. So that's how we selected One Identity for our IGA platform. Now comes the implementation phase. So for the phase 1, we decided what we want to do. We weren't standing up an IGA platform from scratch, or starting an IAM program from scratch, because we had an existing platform from one platform to be moved to another platform. So we had partly custom, partly out-of-the-box code functionality, and we had a lot of data. So we wanted to make sure we took the right approach, a proper approach. So in the first phase, we stick to only lift-and-shift of the existing functionality. We stopped ourselves from getting tempted to add this feature and that feature in the phase I. We sticked to lift-and-shift, and that was a good strategy. And next thing was bringing in an integrator who has a good knowledge and understanding of the platform, which is One Identity, in our case. So for this phase, we had nine months. So we decided what we wanted to do, we had an integrator. The next thing that we did was build a server infrastructure. Now, we have the plan, we have the integrator, and we have the infrastructure. Next thing is to implement, right? But we resisted to implement, and we spent a good amount of time with to build our business and technical requirements. Earlier, while we were having a session in the morning, one of the panelists was saying, requirements are key. The more you work on your requirements, the more defined they are, the better they are documented, it's easy. Your development cycle would be smaller. That's what we did. We saw some of the business requirements were a little old, like when we moved to [? ARS. ?] They are from there. So then we opened those requirements and looked at them and saw, are they still valid? Do we still want to do that requirement, or do we want to update that? So we refined our requirements, and we also worked through our business and technical requirements with the integrator to make sure that both the teams have a good understanding of what's being implemented. Next thing that we did was forming a steering and advisory committee that helped us to keep the business informed and keep them engaged. And also, they had-- I mean, we were able to answer or address any concerns that business had throughout nine months. It was not just for the first month or the last month. It was through the nine months we had that committee going. And we also conducted roadshows across the campus to buy-- I mean, to engage them. And also, there was one more important thing that we wanted to do in this implementation phase, was to decouple the GW email that the user gets being at GW and their user ID. We wanted to decouple them. So that was a big, big win during this project, and I'll talk about that in the next slide. But here, we conducted those roadshows to get the buy-in from our campus partners. We did all that very thorough, very thorough, but still, we had lots of challenges. Not a lot, but we still had challenges. The initial data load and the integration took longer than expected. We thought it would take a certain amount of weeks or months, but it took longer because we were bringing data from two different [? ARS ?] platform and [? OIM ?] platform into One Identity. So different data schemas, different data layouts, so we had to massage data, massage the data sometimes. Sometimes we had to reformat the data. Nd one more thing that you need to pay attention in the implementation phase is data cleanup you want to clean up your data before going to your new platform because you want to remove any orphan records. You do not want to bring any irrelevant data into the platform because, however good and robust your new [INAUDIBLE] platform can be, its functioning is only as good as the data that you put in. Data is very important, and clean data is much more important. We started loading data into our production environment almost a couple of weeks before the actual cut-over. Even though we did that, the cut-over was still a week-long effort because we had to bring down the existing IAM services that were running. We had to bring them gracefully, bring down them, and then do the last final delta data load, and then let the One Identity system process those records. We watched it very, very closely, and only when everything was running smooth, we opened it to our end users. It was a very smooth cut-over, very smooth. We watched the system very closely for two months. Gladly, we didn't find any major issues. During the implementation phase and also the months following the implementation phase, these are the benefits we have realized with One Idendity. Being in Higher Ed, and also these multiple combinations of users, staff, faculty, faculty, alumni, just alumni, students becoming- staff, staff becoming student, all these combinations, because to handle all of this we had a very custom onboarding processes, onboard process, and we had a custom application just to onboard identities. So with One Identity, we were able to retire that application and configure that flow in One Identity with its out-of-the-box onboarding process. And the next thing was the user communication that goes out of an Identity platform-- gain of access, loss of access, change of access, disabling, activation, all those user communication that goes out from identity system, that one, we were able to streamline. And the configuration of when to trigger a communication, on what combinations of affiliations to trigger the communication, all of that was pretty easy to configure. OK, now comes to the decoupling of user ID and the email address. So earlier, before we implemented One Identity, your email address and your user ID was same. So same like Jsmith-- if that's the user ID, and the email address is jsmith@gw.edu. So when a user gives away their email or published their email in papers or for communication, they are also giving away their user ID. User ID is their login throughout the network for different applications. So it's a huge risk, security risk. You're giving half of your credentials with that. So we wanted to decouple that. And another reason to decouple, which is smaller than the first one that I mentioned, is operational headache. It's like people want to change their email address depending on their life events-- like if the last name change, or if they want to go by their first name, or something like that. At that point, they're asking us to change the user ID, so we had to change the user ID and also the email because they were linked together. And because a user is not concerned how their user ID is within the network, they are concerned, how it looks up in the email. So they are asking for change in the email, but not the user ID. So with the decouple, the operations, it's much more easier. Now we can change their email address whenever they request it for, while keeping the user ID constant. With One Identity, the ease of configuration and ease of integrating code has helped us to roll out bug fixes or enhancements faster. And that has reduced our development cycle. OK, auditing. And in auditing, I really like-- I mean, our team really like the auditing part because you can configure how much you want to audit, what data you want to audit, what attributes you want to audit, and you can also configure-- all of this is configurable. And you can also configure-- like when you configure your audit, you can also configure how much of that data you want to save in the main database and how much and when you want to move that to the History database. all of that is configurable. You can configure that according to your business needs, your audit requirements. The in-built Advance incident response, that is helping us stay ahead of things when something happens in the system, something goes sideways. If there is a frozen job, if there is a stuck job, we are notified, the team is notified pretty quickly, and we can address it even before the user notices it-- or the end user, or the other team notices it. And the next thing is reporting. Reporting is really fun and very easy to configure. You can use out-of-the-box reports or configure a custom report based on the out-of-the-box report as a template and build reports. We have built some reports for our customers and businesses. One Identity is providing a good toolset for monitoring and also carrying on your operational tasks. My favorite tools for the monitoring or conducting the operational tasks is Object Browser, where you can select multiple objects at the same time and perform an operation. How much ever you might have configured, there could be some exceptions that you might have to handle, and Object Browser is very helpful for that. Good customer support-- we have seen One Identity stood by us from the minute they started demoing One Identity platform for us. They have given us a very good customer support starting from day one, and it still continues. OK, we have successfully completed our phase 1, which is bringing our custom and out-of-the-box IAM functionalities into One Identity platform, and also all the data that we had. And as enhancements, the first thing that we took up is a request from our HR. So Identity was sending its communication out at the different stages of user's lifecycle, and HR was communicating to the users on its own, and it was a manual process. They were doing it outside of the Identity system, and it was all manual for the hires, rehires, student researchers, and all those. So with that, they came to us and asked us, can you integrate this with the communication that is sent out from the IAM DB system? We said, OK, sure, we'll do that. And then we started how to integrate. We started how we could integrate that and standardize, and now it's all automated. So all of the communication is automated, and it is going out of the central Identity platform, rather than some from the Identity and some from the HR system. It's all in one umbrella now. Currently, we are piloting our RBAC for our ERP system, Ellucian Banner, and Oracle Enterprise Business Suite, and we are also helping Banner upgrade. They are going to Banner 9, so we are also helping with that, the access request related to that, as well. So coming back to RBAC, for our ERP systems, we are doing role mining, analyzing the role and the access the users currently have, and creating role access matrix, understand and build roles for that. Active Roles has served us really well as an interim Identity solution for 4 and 1/2 years, and now we are returning it to manage Active Directory. So throughout the phase I, the communication, and the reach-out, and the engagement that we did with the business, and after the phase I was released, the business could realize what we could do with the One Identity platform. And that has paved us the path for our phase II initiatives. And those are our future tasks or future engagements that we are going to take. And Chuck is going to talk about them. Thank you, Sheema. Nice job. Thank you. So what the future holds, the future is pretty bright. I want to touch first on one of the panel discussions. A gentleman was talking about young talent. This younger generation of technology people, they're sharp. An old dog like me, it's hard to keep up with these young people. An example of that is, we had a young lady who helped us with our PowerPoint presentation. And without her, we couldn't have probably done a lot of this. So a special shout-out-- to her name is [? Shaniha. ?] It's Sheema's 12-year-old daughter. Thank you. [LAUGHS] Woot, woot, right? She has a standing job offer for GW, by the way, when she gets of age. By the way, she is in sixth grade now. [LAUGHS] So some of the things we want to do, we want to extend our entitlements into our ERP systems, right? Coming on by [INAUDIBLE] into our ERP systems and Active Directory. We want to deepen our relationship with our business partners because these applications, oftentimes, technology is seen for technology for technology's sake. This is a business project with an IT component-- a major IT component-- but we need to make sure our business partners are engaged. They own part of this. They own the front end of this. When you look at attestation, you look at accessing your applications in your data and your systems, we deliver that. We enable them to be able to do that and keep that safe and secure. So we want to make sure we deepen that engagement with our business partners. We'll be doing roadshows, and meeting with them, and bringing them in as part of the conversation, which we did early on in the project as well. As Sheema mentioned, we had steering committee meetings and a lot of passions about changing things. We're change agents. We want to support the institution, but people don't like change. So we had a lot of lively conversations about the decoupling exercise. How are we going to do that? What's the impact going to be? Oh my god, it's the end of the world, right? And it's not; it's just change. But we have to manage that change, right? We're looking to do a upgrade soon. It's a software package, so we have to upgrade, which is good. We're looking at role-based access control for our ERP systems. Our Network Team is just going through a major re-architecting of our firewall infrastructure, in so that they're able now to consume our Identity data. So when you enter our network, we know what device you have, and we know who's attached to that device so we can put you on the network where you belong. That's powerful stuff, using the systems to deal with the systems do. We talked about PAM. We're looking at Privileged Identity and Access Management, which is now PAG, Privileged Access Governance. We're going to be implementing that in the near future. So what else we have here? There's a lot of things happening in our future. We're implementing a self-service cloud. Self-service, you think about birthright access. You come to the organization, you get your access, and then, you can day one start doing your job instead of having to submit a ticket, waiting for someone to pick it up out of the queue, provision you, all that. We're going to automate all that. And then, as you do your job, you see you need more access, you can go online, request it, workflow it, approve or deny. And once it's approved, the system picks it up, and you're off to the races. And that also gives us access to the data. We can look at the data in the system and see how things are working. And if we see that everyone who comes into the Finance Group is requesting this additional access, we go back to the business and say, hey, we want to change your birthright access. So everyone's coming in asking for this. Let's just give it to them, right? They say, yep, do it. And we move forward. Lots of opportunity like that. Cloud, we talked about cloud. We want to move into the cloud at some point in time. Cloud-first strategy with the University-- we want to make sure we can abide by that and work toward that. The IAM strategy-- when you think about the University, the University is a very complex organism. It's essentially a small city. We have housing. We have police. We have fire. We have hospital. We have housing. We have restaurants, Post Office. We have every aspect of a small city within the city. And when you look at our residential space, for example, we have our access cards are a one-card system, as we call it, [? GWAL ?] card. It gives you access to the dorms-- residence halls, I'm sorry. "Dorms," I'm dating myself. Food, you can buy food from it, do all kind of services off of that card. But it's not integrated into our strategy yet. We want to be able to do that. We have, during the academic break in the academic year, our residence halls, we have 8,000 beds in the District of Columbia that are sitting vacant. We rent those spaces like hotels. So all of a sudden, we have people who aren't really members of the community on our network. We're giving them all the things you have in your hotel room. So we want to bring that into our system as well and make that part of our Identity environment, improve our security posture-- there's a lot of things around-- and improve our security messaging. So we are part of the security team. There's a lot of opportunity here. So before we jump into questions, I want to give a shout out to the One Identity Quest DLT team for their support. As Sheema said earlier, they've been a great partner. And I've been around the block a bit, and I know the good, the bad, and the ugly when it comes to a partner and a vendor. And these guys are definitely one of the good teams. I mean, they're always here. They're always supporting us. They listen to what we ask. [UPBEAT MUSIC PLAYING] And we're just glad to have them and looking forward to the relationship in the future. So with that-- May I have, please, a huge, huge, huge round of applause for George Washington. Thank you. Sheema and Chuck. Thank you.