Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more

Case Study 4: The Solution Architecture

In this video, you will learn the solution architecture implemented for case study 4 and some of the challenges that manifested.
A GSK used PingFederate and PingID as part of their solution to create a single sign-on process for their various systems. This acts as an identity provider, and it acts as an identity provider for their on-premise services, but also for their other software as a service-based solutions, including access to Office 365. So we have our directory online, our Office 365 service, we have our on-premise directory service – PingID is being used to tie all of these together. They also use this to implement multi-factor authentication to help improve security in line with the new single sign-on credentials. So these credentials have become far more valuable, far more capable, in that they access a broad range of services.
And so multi-factor authentication became a key requirement. Interestingly, with PingIdentity, it doesn’t store– it’s one of the few providers that actually doesn’t store the identity information in the cloud. So it’s tying all of these different services together. It’s helping to federate all of these different services. It’s providing the multi-factor authentication. But it can help address some of those PII requirements by not storing an identity in the cloud. So some of the challenges then with the solution, we have the integration with the existing line of business systems. Some of these systems are niche, science and research type systems, and they do not offer APIs for integration. They’re not necessarily the bigger, well known systems, like Salesforce or CRMs or ERP systems.
Also, because the identity information is not maintained in PingIdentity, we need to make sure that there is sufficient resilience for the on-prem solutions, and also for the links between those on-prem solutions that provide the IDP type services and the PingID. So we need to– if we’re using PingID, but the ID service is stored on-prem, the ID service has to be resilient and the access links between PingIdentity and the on-prem ID must be very, very good. Must be highly resilient. So let’s take a very quick look, then, at the way this works. We have the IDP with a single sign-on service in the top left there. And we see SAML being used to provide a browser interface to process the log-ons.
And we have the service provider in the top right, with a federation server and a target resource. So this is a very strong model, a very secure model. We have simplified our access to a single sign-on approach for the end users. And, also, we’ve implemented multi-factor authentication to provide the increase in security.

In this video, you will learn the solution architecture implemented for case study 4 and some of the challenges that manifested.

Once you have watched the video, recap the challenges below:

  • integration with line-of-business systems was difficult to maintain as there was ongoing change and some lack of integration capability for niche systems
  • because no identity information is stored in PingIdentity, GSK would need to ensure there is sufficient resilience with the PingIdentity systems and services
This article is from the free online

Cyber Security Foundations: Reinforcing Identity and Access Management

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now