What is our primary use case?
We use OneLogin for single sign-on to provide a consistent user experience with our in-house and external third-party applications. In addition to single sign-on, we use two additional modules: two-factor authentication and self-service password reset. It's a SaaS product.
How has it helped my organization?
Previously, users constantly had to log in with their user ID and password. It was the same user ID and password for all these applications, but they had to authenticate when they used all the applications they needed to use daily, whether they were an employee or a student. They would authenticate into one application and bounce over to the next to log in again. That's a huge benefit that the organization is leveraging with OneLogin.
The other benefit is that we've reduced calls to our help desk for password resets. Staff and students can now reset their passwords using their enrolled two-factor device as the authentication mechanism. In the past, we were using secret questions through a self-service portal. Inevitably, they would forget their answers or type them wrong. It just wasn't user-friendly.
We're always onboarding new students, and we can set a default profile. Each student has access to a default set of applications, but when they enroll in a class, they might get access to other applications. They're active students, and all that is happening dynamically. We use data feeds from our student integration system to determine student roles and access to applications. We don't need to do that manually. OneLogin can set up those mappings for us automatically based on their enrollment.
It helped us manage our growing user base because we can use data from our SIS and HR platform to drive secure access to applications. Before this, we didn't have the capability. Either everybody got it, or we had to provide access through a request to our service desk manually. I won't say these requests have been eliminated. Still, they have been drastically reduced because we can pull that data feed from those two record systems to provide some access, reducing the workload on the systems and the security team.
With OneLogin, we use the same validator as our login: an authenticator application or a text message. That same two-factor authenticator is used for the password reset. We've significantly reduced the number of trouble tickets and tier-one service desk calls because everyone can reset their own password.
The adoption rate is high because we don't give users a choice. When we add new applications to our portfolio, IT is part of the process on the procurement side. When reviewing a request for an application, one of the first features we look at is the single sign-on capabilities. Do they do SAML? Do they do open ID?
We approve the purchase if all those features check out because we can connect third-party applications for single sign-on. IT is part of the first step. They don't get a choice on the front end of it. IT ensures the application can meet the requirements. We protect that app with two-factor authentication.
We allow a little flexibility on user enrollment in 2FA. It requires some custom development work to make this happen because the functionality isn't native to OneLogin, but we allow a grace period for students to enroll. We didn't want to force enrollment on them right out of the gate. Brand new accounts are required to enroll. We wanted to prompt them, "Hey, here's what you need to do. You need to enroll in two-factor authentication. You have 30 days to enroll in it. Here's a tutorial telling you how you enroll." They can enroll at their leisure.
After 30 days, you don't get any more opportunities. You're forced to enroll. You can't log into any system until you've enrolled in two-factor authentication. We force it on them, but we give them a little time to ensure they have an appropriate device and they've read through the knowledge base to learn how to do it.
Before OneLogin, we had some SSO in place. It was all custom-developed integrations by our in-house developers, but it was never the same. We had a custom SSO for each vendor. By adopting OneLogin, we could reduce the development time. It's not the developers' job anymore. That responsibility shifted to my systems integration team. It reduced the manual effort needed to provide a single sign-on experience. Now we have a true single sign-on experience with few onboarding requirements for connecting to third-party applications with OneLogin because it uses a standard like SAML or Open ID.
These days, more students and staff are working remotely. They still have the same experience they had on campus, but we're protecting their accounts with 2FA. The world was told to work from home at the pandemic's start. We didn't have two-factor before that, so COVID was a significant factor driving the push to make this mandatory for all our staff.
We do not control the network they're on, but we see authentications happening all over the place. People weren't just staying in their city anymore. They traveled to some extent after restrictions were removed and logged in from all over the country. How do we validate that these accounts weren't compromised? The two-factor helped the security side to ensure these authentications are legitimate. At the same time, they provided a secure environment for telecommuting. They won't be denied access to those systems because their account was compromised.
I believe we've saved money, but I'm not sure I can quantify it. In August, we'll review our help desk tickets for password resets. That's one area where I think we'll save money because our calls have decreased. I don't know how much they've declined, but our call volume should be down.
We can also review our application use through the OneLogin portal, which could save us some money on under-utilized licenses. For example, we might have 100 licenses for an application, but only 25 users access it annually. It gives us the data on who's using the application and how frequently to help us make these decisions. That said, we don't have that data yet to quantify how much we're saving, but we will review it after using the platform for a couple of years. As the contracts start coming up for renewal, we can use that data from OneLogin to renegotiate better contracts with vendors.
What is most valuable?
In my role, the most valuable features are two-factor authentication and self-service password reset. The most helpful feature for the institution as a whole is probably the single sign-on. As an IT director, I care about security and ease of use.
OneLogin provides a single pane of glass for events that happen within our organization on applications that are connected. We can see logins, sign-outs, password changes, two-factor prompts and failures, failed logins, etc. It's a crucial feature. We scraped those logs and sent them to our SIEM and SOC to look for anomalies and vulnerabilities. Having them in a central place in OneLogin streamlines that process for us.
We want to review those logs proactively. In addition to OneLogin's risk analysis, we want to pull it into our SOC and have them take a deeper look. They pull in additional data points to see anomalies in OneLogin, Office 365, and the network. They can piece together some events that we need human eyes on. Having them in one spot makes it easy to get to that point.
We use Webhooks for two items. One is the enrollment grace period. The other one is to capture data in our SIEM for our SOC to review. Those are two development Webhooks that we're leveraging. We still run some custom items on our servers to leverage those Webhooks. One is the enrollment grace period. Webhooks can use the data from OneLogin and manipulate it on-premise. That's invaluable. We could not have done our enrollment process without that Webhook. It wouldn't have been as nice of an onboarding experience for our users. It would've been more troublesome for them.
Webhooks freed up a tremendous amount of time. We looked at it from the perspective of maintaining this long-term. Enrollment in 2FA isn't a one-and-done. We have students coming every day. It's not like we're done once we get everybody enrolled. Our onboarding is never-ending. There was no way we could maintain that on a user-by-user level. It was going to be a manual process. Webhooks allowed us to provide that pleasant experience without needing to manage this in the future.
We didn't initially have SmartFactor when we started the contract, but we saw the value. We don't feel comfortable prompting our users to validate using their two-factor enrolled device each time they log in. We only use SmartFactor when a change in user behavior is detected. For example, maybe they're logging in from a new device or an IP address the system hasn't seen before, which raises their risk score. That's when we prompt for that authentication, for that two-factor authentication.
If you're sitting in your office and logging into the same computer simultaneously from the same IP address, there's no need to keep prompting you for the two-factor authentication throughout the week. We only ask for it when something changes. For example, if you take your computer to a coffee shop, you will get prompted because that's unexpected user behavior that the system hasn't seen.
It's a good compromise between security and usability. We haven't moved to password list technology, but OneLogin has the capability. We still require a user ID and password as the front entry, followed by two-factor authentication as the validation that you are who you say you are.
It has a risk score based on user behavior anomalies, like login location, time, and device, usability and security, and more. There's a good balance. The two-factor authentication offers protection, but we don't want to bombard you with two-factor prompts when you're just trying to do your job. We only want to do it when something has changed about your login behavior.
We use the OneLogin Desktop feature in a limited capacity for some self-service kiosks around the organization for payment stations. Students can make payments using a single sign-on via the desktop. Because the application is doing authentication behind it, we haven't extended the OneLogin Desktop to staff or student desktops. One of the main reasons is there's not a great way within the service portfolio that OneLogin has to use the desktop but pick and choose what applications will do single sign-on.
What needs improvement?
We've been a OneLogin customer for several years now. While I like the platform, there have been some challenges. A great example is the amount of work needed with that webhook for the enrollment user experience. This functionality is native to some competing products. That's one area where we've leaned on our account rep over the years. They shouldn't rely on the customer to make this experience better. This is one feature request that hasn't been implemented yet.
At the same time, they've implemented other features we've requested. One is the ability to use a personal email address as a factor. Initially, they didn't have that. We pushed hard on our account team for about two years before it was finally released.
It's a give-and-take. Some of the product's features aren't perfect, but we've had some success pushing fixes to the development team that needs to happen. They've done a decent job. However, there are some fixes that they don't have an interest in. A lot of what I described was before OneLogin was acquired by Quest/One Identity. Things have changed. It doesn't feel like they're driving the product as OneLogin was. It may be because it's a new product to them, and they're still trying to get the lay of the land, process feature requests, etc., but it's not moving as fast as before.
We've been experiencing some pain points since the acquisition. For example, there have been some outages we didn't see previously, which are a big topic with my executive team. You have hundreds of applications relying on this service for login. If the service is unavailable, nobody can log into these applications. The issues have high visibility. It's gotten better, but it's still there. It raises questions about whether One Identity can support the platform they've acquired. How are they enhancing the product? And how are they supporting the product and the service in the future? Those are two essential questions. There are also lots of nice-to-haves, but that's the case with any product.
For how long have I used the solution?
I have been using OneLogin since 2019.
How are customer service and support?
I rate OneLogin's support a seven out of ten. My evaluation of OneLogin's support depends on whether we're talking about before or after the acquisition by One Identity. Initially, we didn't have any problems. They were quick to respond, and it was easy to get ahold of them. When we first started using OneLogin, I would rate the support a nine out of ten.
We've experienced some pain points since the acquisition. When we had a service outage, we had trouble getting through to someone. They're trying to streamline this and provide customers guidance on communication channels. At one point, their phones were offline when they had an outage. Their tier-one support portal to escalate a ticket was unavailable. It was the perfect storm. That was a terrible experience.
Since then, they've tried to break some of those dependencies, so you can log into the portal when there is an outage. They've updated their status page, so it isn't dependent on the rest of their services. It is getting better. One of our challenges is determining whether an issue is a feature request or a bug. Our account manager tells us something is a bug, while the support staff keeps telling us it's a feature request that will be on the roadmap. Indeed, it's a bug that needs to be addressed. It's an issue. The product's not doing something, and we're not asking for something new. We've had to get our account manager involved a couple of times in that scenario. I can think of two cases we've had for that.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
In 2017, we bought a product that seemed like it would solve all our problems on paper. It was going to be the greatest product ever. However, when it came time to implement it, we learned that the product we were promised didn't exist. It was a challenge to get everything to work. It took us six months to onboard a single application for single sign-on. That is no exaggeration. When we moved to OneLogin, we could onboard that application in minutes.
We purchased another product, but we ultimately realized it wasn't a good fit for us as a customer or for them as the provider. They were just as frustrated as we were that they couldn't perform to our level of expectations even though we're talking about a basic core service they couldn't provide. Before that, everything was developed in-house. We had custom-developed solutions to make single sign-on work.
How was the initial setup?
Setting up OneLogin is straightforward. Their onboarding is streamlined, and the onboarding engineer was knowledgeable of the product. We were up and running on our basic apps quickly, and they were responsive during the onboarding process. We had a nice onboarding experience with checklists as we went through and got the service operational. The onboarding experience was great.
We had three system admins from our organization. It was me and two of my employees. After deployment, it requires little maintenance. We use the product rather than maintain it. We add new applications to the portfolio, look at the logs, and check in on some of the processes that we built around it.
What about the implementation team?
We worked with an implementation consultant, a professional services manager, and an implementation consultant from OneLogin. Once our contracts were all signed, we had our account manager who brought in the onboarding engineer. We scheduled regular calls with that onboarding engineer to work through a checklist of what we needed to do to start leveraging the service in production.
What's my experience with pricing, setup cost, and licensing?
I don't know what will happen at the end of my five-year contract. It's no longer purely OneLogin. Now it's OneLogin by One Identity, so I don't know about their current pricing model. Price was a deciding factor when I bought the product several years ago. When we compared products, OneLogin had a price advantage over similar services. However, we found that their competitors could do things OneLogin couldn't.
We were happy with the price we got when we signed up, but I don't know what will happen when the time comes to renew because it is a different company now. We haven't seen any pricing models or had that discussion yet. My renewal is a year and a half away. It's worth what we're paying for it. There's no way we could provide the level of service for cheaper or try to do the same in-house.
Which other solutions did I evaluate?
We evaluated some of the competitors in the market and got a recommendation from another college in our state that we work with on other projects. They were using OneLogin and gave a glowing recommendation. That's how we ended up finding OneLogin and doing a demo. We also talked to some similar service providers out there.
Which deployment model are you using for this solution?
Public Cloud
*Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.