Integrating Third-Party Identity Services
Integrating Third-Party Identity Services

This course is the final module of Domain 5 of the CISSP, covering Identity and Access Management.

Learning Objectives

The objectives of this course are to provide you with an understanding of:

  • Identity as a Service
  • Integrating 3rd party identity services
  • Implementing and managing authorization mechanisms
  • Preventing or mitigating access control attacks
  • Managing the Identity and access provisioning lifecycle

Intended Audience

This course is designed for those looking to take the most in-demand information security professional certification currently available, the CISSP.


Any experience relating to information security would be advantageous, but not essential.  All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.


If you have thoughts or suggestions for this course, please contact Cloud Academy at


We're going to go on to section six and we're going to talk about the integration of third-part identity services. So managing user accounts with a cloud-based application and a directory solution, we have a couple of different examples that we're going to explore. It is possible to manage user access to cloud computing resources in house, but the architecture must take integration complexity and management costs into account. Most organizations find that these inconveniences outweigh the benefits. For many the same reasons including on-demand self-service, elasticity, broad network access, reduction in capital expenditures, and so on, companies adopt cloud computing services instead of in-house services. And they also leverage third-party cloud services to manage identity and access across the enterprise.

A practical example of the challenges faced by the security architect in this area can be illustrated by examining any of the cloud service directory providers that offer services to the enterprise. For example, Microsoft, Amazon, and Oracle. Now, the first thing we need is a basic working definition of what a directory service is and what it provides the capability to do. So we're going to look at three different examples of how this is done.

When it comes to cloud identity, users are created and managed in the Office 365 implementation and are stored in the Windows Azure Active Directory instance. Now, there is no connection to any other directory. And what this means is is that the cloud identity has no integration requirements and each user is created once in the cloud and the account exists only in the Windows Azure Active Directory.

A second example is the directory synchronization where users are created and managed in an on-premise identity provider's software and are synchronized to Windows Azure Active Directory where they can be used for login to Office 365. Now, this directory synchronization uses an existing on-premise directory and synchronizes it to the Windows Azure Active Directory instance. Synchronization, of course, means that the accounts are managed on-premise and properties cannot be edited through the Office 365 cloud interface.

A third form is federated identity. In addition to directory synchronization, login requests are handled by the on-premises identity provider. The federated identity is usually used to implement a single form of single sign-on. Now, the federation provides for a user to be signed in using the federated identity for the passwords check. Directory synchronization is also required as a prerequisite in order to populate the cloud-based directory.

Now the security token service providers that you see listed on this slide represent a great deal of the market for this kind of service. Because these represent vendors of products, vendors specifically will not be on the examination. But these represent the majority of those providing the service and it shows just how much interest there is in this particular service being offered in the cloud.

So let's take a look at the Amazon example. Looking at this, we have the Amazon Identity and Access Management service. The service supports Amazon, Facebook, and Google identity federation which allows these to grant temporary authorization to people using these services. All the server-side code is managed without long term credentials for the app. The service introduces a new AWS Security Token Service API that allows for temporary security credentials for customers who had been authenticated by, Facebook, or Google. According to the AWS blog, the app can then be used to provide temporary security credentials to access AWS services such as Amazon Simple Storage service, or S3, DynamoDB Tables, or Amazon Simple Service Queues. This, of course, is simply one example of one vendor that offers this particular type of service.

Another example is a public service provided by the Australian government. Because of the nature of the island continent of Australia, it has a very widely dispersed population with a great deal of infrastructure on its coast, but not much through the center. This means that the government is out of direct touch with a great portion of its population on opposite sides of the island. So the Australian government has made investment into technology to make sure that the island's population is properly and continuously connected for both news and other kinds of programmatic information for the population. They're minimizing investment in new authentication infrastructure and maximizing ease of use by reducing the number of authentication credentials required to access these services for the population of their country.

About the Author
Learning Paths

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.


Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.