Protect your custom web application with IBM Security Verify

— HOW TO

Start using SSO in your custom-built web applications

The fact is, you are not going to be able to rely on Windows Authentication to protect your internal web applications for much longer. These days end-users expect to be able to utilise services through their phones. Each year you’ll find web applications increasingly built for microservices environments like Docker or OpenShift.

If you’re a Corporate or Public entity using MaaS360, then IBM Security Verify may be bundled in with your MaaS360 subscription. As such, let’s plan for that future by exploring how to protect your .NET web applications using IBM Security Verify – an entitlement you likely already own.

The code examples within the Github repo are about protecting our .NET web applications with IBM Security Verify using OpenID Connect (OIDC). That’s only because .NET Core is our preferred programming language. While code may be different for other programming languages, the implementation and benefits are the same whether you’re using .NET, Java, Python, Go, NodeJS, PHP, Ruby, etc. As such, the contents of this article are still very applicable if .NET is not your preferred programming language. The same applies if you’re using OIDC or SAML – both of which IBM Security Verify supports.

Regardless of your preferred programming language, if you want to understand why you should use IBM Security Verify as your IDaaS, below is some further reading that goes through a few of the benefits, along with videos showing the features in action.

Things you will need:

X

How-To IBM Security Verify

Cyber Security IAM

The best way to be alerted about our new news articles is to follow us on Twitter or LinkedIn. If you’d rather be notified by email, fill out the form below.

Scan the barcode below to open this article up on your mobile device and continue reading this on the go.

Let’s get two key questions out of the way…

Two questions that are almost always asked is Why not just use Windows Authentication? Or, Why not just use Azure AD? If you already know the answer to both of those questions, skip over the next two sections below.

Why not just use Windows Authentication?

Let’s start with addressing this question because the answer is simple. Windows Authentication is excellent for Windows – not much else. Chances are your end-users are using mobile devices, macOS or Google Chromebooks. The sign-in experience is less than ideal for end-users on those platforms when they use web applications protected using Windows Authentication.

We also cannot ignore a universal truth. Every year, the chances of you developing a web application using Windows Authentication goes down by half. Traditional web applications hosted in IIS are becoming a niche setup because they require a web application server. That means you need to protect another server with AV, backup, patching, and monitoring. Today, all industries are undoubtedly moving towards a microservice approach to development, running web applications in the cloud, or on-premise using OpenShift or Docker. Windows Authentication is not available on those platforms. I am not saying you can’t find some niche and painful way of getting it to work. I am simply saying, supporting Windows Authentication in the Cloud or in a Container is tricky, painful, and even then, a niche within a niche.

Why not just use Azure AD?

In a later article I will be doing a deep dive into this, but at a high level, IBM Security Verify can and will work well with Azure AD. If you configure IBM Security Verify as an identity provider to Office 365, all of your bespoke web applications you previously developed with SSO through Office 365 will continue to work exactly as they did before, without any code change.

That said, why would you change if you already have Azure AD through Office 365? Well, there are quite a few key features that exist in your IBM Security Verify entitlement bundled with your MaaS360 subscription that does not exist in the base Azure AD entitlement that comes with your Office 365 subscription. And, for organisations with an Enterprise Microsoft 365 subscription that includes Azure AD Premium, you need to be careful because there are two versions of Azure AD Premium (i.e. P1 and P2), and chances are a lot of the features you compare between IBM Security Verify and Azure AD require you to purchase an Azure AD Premium 2 add-on – which sends your subscription price up much higher.

What are your goals?

Below I’ve listed some of the main benefits of using a service like IBM Security Verify. Because I will be doing a deep dive into each of these features at a later date, I’ve tried to stay high-level. This article will focus on IBM Security features like Risk-based MFA using AI, Delegate Access Control, Access Certification, Identity Analytics, and Account Lifecycle management.

Ease of use

Obviously, the most important objective is to have an SSO experience for your web applications compatible with today’s PCs but ready for tomorrow’s mobile devices. To your end-users, that experience needs to be as seamless as it was for your web applications using Windows Authentication. Users need to sign in once, and that sign-in session must be shared across the multiple platforms and web applications they access throughout the day. SSO gives you precisely that. The user authenticates once for the day, and their session is shared across the various other web applications and platforms they access, also protected with IBM Security Verify.

Security based on AI and risk-based MFA

Another obvious benefit is that you can now introduce multi-factor authentication to your web applications. That said, protecting your applications requires a delicate balance of convenience vs security. IBM is no doubt a leader in Artificial Intelligence and has been for decades. How IBM has integrated that AI experience into IBM Security Verify is where IBM and their investments in AI begin to shine.

IBM Security Verify has AI built into their platform, allowing you to make MFA challenges risk-based. Meaning, IBM Security Verify looks at the end-user’s behaviour and other contextual data sources to calculate a risk score, then uses that to determine if it should challenge the user with an MFA prompt. For example, when John visits your web application protected with IBM Security Verify, because John just completed a 2FA prompt in another application a few minutes earlier, IBM Security Verify won’t challenge him for MFA again, especially if John is accessing your web application from the same device and geographic location. Now, risky behaviour (e.g. signing in from two different countries within 24 hours) would trigger an MFA challenge.

So remember, it isn’t just about signing in, or having the ability to do an MFA challenge. If security is really what you are after, you should invest in a platform that analyses end-user behaviour, only prompting 2FA when a risk is identified.

Delegate Access control to Supervisors, rather than the IT Help Desk

IBM Security Verify includes a feature called Delegate Access Control. Instead of users sending tickets to the Help Desk requesting access to the application you develop, from the LaunchPad, users can request access to your application. When their manager approves the request, the user is automatically given access to the application.

This cuts down on the number of tickets sent to the Help Desk where awarding access to applications involve adding users to Active Directory Security Groups. It also helps prevent your Active Directory from becoming a boneyard of once-important-but-now-abandoned Active Directory Security Groups. All of this is audited, obviously. So your IT team and compliance officers still get an audit trail showing who has access to what, and who authorised that access.

Access Certification (a.k.a. Access Review)

Do you perform period access reviews within your organization to make sure staff have access to the applications they need? Do you have good practices within your organisation to make sure access is removed from applications once staff no longer require access? The good news is that this is built into IBM Security Verify:

Use IBM Security Verify to distribute out periodic access review requests to management. Managers can themselves approve or revoke access to bespoke and third-party applications without needing to involve IT. The AI features in IBM Security Verify will even identity outliers where a member of staff has exceptionally higher access than their peers within the same role, allowing you to automatically (or your Compliance Officer to manually) trigger recertification requests to line-of-business Managers or Application Owners.

Account lifecycle management via SCIM

As the number of applications used in modern organizations continues to grow, IT admins are tasked with access management at scale. Standards such as SAML or OIDC allow admins to quickly set up SSO, but access also requires users to be provisioned into the app. Solutions like Just-in-Time (JIT) help relieve the burden associated with onboarding a user, but enterprises also need a solution to deprovision users when they leave the organization or no longer require access to certain apps based on role change. This is where the System for Cross-domain Identity Management (SCIM) 2.0 specification comes in handy for provisioning and de-provisioning, something IBM Security Verify also supports.

Most SaaS platforms support SCIM right out of the box. This means you can implement SCIM with most of your cloud systems right away. In a future review of the code examples, we’ll provide sample code showing how to include support for SCIM in your bespoke applications.

Identity Analytics (i.e. Reporting)

One of the most important benefits of using an Identity Provider like IBM Security Verify, is Identity Analytics. When your application is protected with IBM Security Verify, you get an audit trail showing each time a user accessed your web application, where and what device they accessed from. IBM’s AI algorithms use this information to flag risks when it notices changes in behaviour. And, you can create and run these reports yourself from IBM Security Verify, or have these events stream to a SEIM like IBM QRadar.

Consumer Identity and Access Management

IBM also has a version of IBM Security Verify that your customers can use to sign in to your portals called IBM Security Verify Consumer Identity Access Management (CIAM), identified by Forester as a leader in CIAM. This identity service allows you to protect your customer portals using enterprise-grade SSO technology developed by IBM, backed by their AI-based risk analysis benefits provided through Trusteer.

Not only can you use IBM’s CIAM to protect the off-the-shelf customer portals you buy from vendors, but you and your developers can also expand the features available in those portals and develop your own add-ons services. This means you do not need to ask for any code changes in your third-party customer portal service. Instead, your developers build a microservice add-on protected with IBM Security Verify Consumer Identity Access Management and simply link to it. Using one platform that can protect corporate and consumer portals allows your developers to leverage their experience in developing solutions in both environments continuously.

Timothy Dilbert

Hi! I've been in software development and system integrations for 15+ years. During my tenure I've had the pleasure to work with schools, regulators, utility companies, law and finance firms from all over the globe. My current interests are SharePoint, Identity & Access Management with IBM Security Verify, Openshift, Ansible and IBM Cloud Paks.