Identity as a Microservice

header.png

Overview

Microservices allow applications to be created using a collection of loosely coupled services. The services are fine-grained and lightweight. This improves modularity and enables flexibility during the development phase of the application, making the application easier to understand. When designing applications, identity becomes a key factor to building out a personalized user experience. Identity also enables other microservices for tasks like authorization applications like Axiomatics, single sign-on, identity management and compliance.

However, access to profile data presents a challenge since it is contained across multiple repositories, contained in other applications or even must be consumed from other microservices. The Identity Microservice must be able to not only respond to requests through a standard protocol for identity information, but must also have the means to reach out to these identity repositories in an efficient and responsive manner. The Identity Microservice must also allow for both user-driven and server-to-server access to identity data.

The following diagram breaks down the components of the Identity Microservice:

The Identity Microservice at its core is made up of four layers:

  1. oAuth Authorization Server
  2. OpenID Connect UserInfo Endpoint
  3. Federated Identity Service from applications like Radiant Logic’s FID
  4. The server and web application clients of the Identity Microservice

Each of these layers performs a crucial role in securing access to identity data and also allows the microservice to obtain identity data from the required repositories. Breaking this down further:

  • The oAuth Authorization Server provides secure access to the Identity Microservices
  • The UserInfo Endpoint handles the requests for identity data and returns the requested profile information (claims)
  • The Federated Identity Service provides a centralized hub for obtaining application-specific profile data from directories, applications, databases and other microservices
  • Additionally, the Federated Identity Service needs to be able to aggregate and correlate profile data and leverage a real-time cache to ensure that access to profile data performs quickly and within the required application service levels

Today, the Identity Microservice’s components are based upon open standards and are both lightweight and highly leveraged by web applications and servers.

There are two main client flows supported by the microservice:

  1. User-driven Web Application flow
  2. Server-driven flow

Each of these flows require a different means of interacting with the Identity Microservice.

User-Driven Web Application Flow

Identity is at the core of nearly all web applications - everything from the initial authentication and authorization through to personalization with profile data. When logging into your banking application you not only need to securely identify you as the user, but also must authorize access to your accounts and personalize the site for your profile. Would you trust a banking application that listed your identity as “User”?

The following diagram breaks down the user-driven Web Application flow:

  1. User accesses the Web Application
  2. The Web Application redirects user to the Identity Microservice’s Authorization Server with a client ID and application scope
  3. User authenticates and authorizes request
  4. Authorization Server redirects user back to the Web Application with an authorization code
  5. The Web Application sends the authorization code to the Authorization Server with its client secret
  6. The Authorization Server returns an access token and ID token
  7. The Web Application sends the access token to the Identity Microservice’s UserInfo endpoint
  8. The Identity Microservice’s Federated Identity Service matches the application scope to the defined view and returns requested attributes
  9. The Authorization Server returns the requested user information (claims) from the UserInfo endpoint to the Web Application

There are several key factors in this flow:

  1. The scope sent to the Identity Microservice is the application, or view, for the requested profile data
  2. The view defined in the Federated Identity Service is application-specific and can be limited to just the profile data needed for the authorized application
  3. Multiple application-specific views can be supported by the Identity Microservice
  4. Authentication can be easily mapped back to the user’s profile repository by the Federated Identity Service allowing client web applications to completely delegate authentication to the microservice

 

Server-Driven Flow

While similar to the user-driven Web Application flow, no user interaction is present for this transaction. The Server-driven flow allows for backend access to profile data. In this case, the server is being authenticated and not the user.

The following diagram breaks down the Server-driven flow:

  1. Server sends client credentials and application scope to the Authorization Server
  2. Authorization Server returns an access token and ID token
  3. Server sends the access token to the UserInfo endpoint
  4. Federated Identity Service matches the application scope to the defined view and returns requested attributes
  5. Authorization Server returns the requested user information (claims) from the UserInfo endpoint to the Server

This allows the server to access the same profile data as defined for a Web Application. Additionally, the same views in the Federated Identity Service can be leveraged, if desired, for both Servers and Web Applications.

The Identity Microservice allows for powerful, yet lightweight access to all the needed profile data in an efficient manner. This microservice can provide what is needed at the core of all applications, and for the Server-driven flow can even be used for transaction-specific data unrelated to users. As the world moves toward the model of easily consumable services, the Identity Microservice must be one of the main considerations when designing an application.

CA Access Gateway Install Error: "JRE libraries are missing or not compatible"

bigstock-New-Version-Software-Install-H-127067990.jpg

We ran into a problem during a recent installation of CA Access Gateway 12.6 (formerly known as CA Secure Proxy Server) on Red Hat Linux, and would like to share the solution. 

Upon launching the installer, the following error was displayed:  "JRE libraries are missing or not compatible..."

access_gateway_install_error.png

This may have to do with insufficient permissions in the /tmp directory.  In environments where obtaining the required permissions may not be straightforward due to how the server is locked down, security policies, etc., there is a simple workaround.

You need to create a new "temp" directory in a location where you do have the proper permissions (for example, /opt/myapplication/tmp), and then set an environment variable called "IATEMPDIR".  Example:

mkdir /opt/myapplication/tmp

export IATEMPDIR=/opt/myapplication/tmp

You should not be able to successfully launch the installer without encountering the "JRE libraries are missing or not compatible" error.

Good luck!

Virtualize SailPoint IdentityIQ's Database with RadiantOne!

CoreBlox Senior Architect Anthony Hammonds recently participated in our partner Radiant Logic's webinar focused on how to virtualize SailPoint IdentityIQ's database with RadiantOne such that it can be easily extended for use with LDAP applications, WAM systems, and Federation. The webinar playback and presentation can be found on Radiant Logic's web site:

http://www.radiantlogic.com/learning-center/events/webinars/y2017/webinar-612017/

As always, please contact us if you have any questions about Radiant Logic or SailPoint solutions!

Creating a ToolBox for the Modern Software Factory

bigstock-Toolbox-81236894.jpg

If you’ve recently visited ca.com then you’re probably aware of CA Technologies' focus on the evolving needs of the enterprise as it builds the “Modern Software Factory”.  At CA World 2016, CEO Michael Gregoire used his to keynote to discuss companies that are built to change. Otto Berkes' keynote described what a Modern Software Factory is and why enterprises need to streamline innovation so that ideas can turn into new customer experiences quickly and efficiently.

He identified 5 key principles of a Modern Software Factory:

  1. Agility
  2. Experience
  3. Automation
  4. Security
  5. Insight

    It was a fresh perspective on the challenges our customers face and how to meet them. I recently found myself reflecting on how CoreBlox, a CA Focus Partner, is already aligned with the vision for the Modern Software Factory. Many IAM industry people know of our architecture and services delivery capabilities, but we are also a software company. Our CoreBlox Token Service allows CA Single Sign-On to securely exchange tokens with PingFederate, an increasingly common need within large organizations that have security solutions from multiple vendors. Our ToolBox for CA Single Sign-On automates and streamlines common CA SSO administrative tasks while increasing overall security and easing regulatory compliance. Developing, refining and supporting these products has given us a taste of what it's like to run our own Modern Software Factory. But how do they contribute to our clients' own ability to adapt to an ever changing market?

    Here is a breakdown of how ToolBox for CA Single Sign-On embodies the essence of the Modern Software Factory:

    • ToolBox allows you to be Agile in your daily security management practices. It enables you to easily promote SSO policies across environments and seamlessly onboard new applications.
    • ToolBox helps to drive ever evolving user Experiences. Companies that are releasing new applications and on boarding new users daily need to be able to control access by defining new policies and updating existing ones. ToolBox centralizes the management of these policies across environments so that the user experience is consistent and predictable.
    • ToolBox is the Automation engine for CA Single Sign-On. Its intuitive user interface makes most of your common administrative tasks as simple as pushing a button. ToolBox's template-based approach makes it easy to re-use configurations that have already been created. 
    • ToolBox was designed to bring Security to your CA Single Sign-On operations. With ToolBox, you'll be able to delegate administrative functions and precisely control user access across environments. Simplified policy testing allows you to eliminate errors that cause unintended vulnerabilities. With all of your environment changes audited, compliance requirements are easy to fulfill.
    • ToolBox delivers Insights into how your security policies are being configured and the subtle differences between your environments that could impact user experiences. Its optimization functions highlight subtle configuration tweaks that can improve performance and allow CA Single Sign-On to grow and change along with your business.

    CoreBlox is committed to building products and solutions for the Modern Software Factory while incorporating its key principles into our own day to day experiences as a software company. We're excited to be aligned with CA Technologies on this quest! 

    Unofficial CA Single Sign-On Guide, Chapter 2: The Installation Debugger

    (This is the second chapter in our new series, the Unofficial CA Single Sign-On Guide. You can find Chapter 1 here.)

    I’m sure you’ve seen it! Whether it was on one of those tacky motivation posters or during a 3 a.m. Tony Robbins infomercial… the concept of "trust". It is usually demonstrated by somebody blindly falling backwards and trusting their partner or team to catch them. It looks convincing when you see it on television, but if you are like me you start wondering how many takes it took to make it look that easy. I believe it is part of human nature to want to ‘Trust’ but in the end we usually go with ‘Trust, but verify!’. That verification piece is especially important when it comes to your SSO solution!

    If you have installed a CA security product in the past, you have no doubt seen one of the following conclusion messages: ‘Installation Successful’, ‘Installation Successful but with errors’ or ‘Installation Failed’.  Unfortunately, these messages are not always accurate. I have seen successful completions that were…. well…not successful. Other times it was successful with errors, but when you review the installation log there is little to no information in it.   So, what is one to do?

    This brings us to the installation debugger. It is not in the manual, and often when I am on-site with a client they have no idea this function even exists but Yes, Virginia: there is a debugger!

    Below are the methods for starting the debugger during Windows and Linux installations of CA Single Sign-On:

    Windows

    Running the debugger in Windows is very simple. Once you start the installer just hold down the [Ctrl] button during the initialization screen (see below) until you see a DOS box pop up in the background.  Once the DOS box has opened you can release the [Ctrl] button and continue with your install.   One important thing to note for Windows is that the DOS window will close once you have exited the installer so before you hit that final button to exit, be sure to select all the content of the DOS window and copy and paste to a text editor so that it can be saved for reference.   

    Initialization Screen - Hold down the [Ctrl] button until you see the screen below then release the control button.

    Initialization Screen - Hold down the [Ctrl] button until you see the screen below then release the control button.

    You know the debugger has started once you see this DOS window pop-up in the background.

    You know the debugger has started once you see this DOS window pop-up in the background.

     Linux

    Unlike Windows, running the debugger in Linux will automatically write the content to a log file. 

    Before running the installation script, enter the following command (note this command could vary slightly depending on the shell in use)

    export LAX_DEBUG=true

     Then start the installer script as you normally would.

    Running the debugger during the installation will not ‘fix’ a potential problem, but it may provide some specific information (or errors if you are lucky) to assist you with finding the source of the problem so that you can resolve it.

     

    Extend CA Single Sign-On with Axiomatics!

    Two decades in the Identity & Access Management space has exposed us to our fair share of “where did we go wrong?” scenarios - organizations that thought they were following best practices and ended up creating problems for themselves over time.  One especially problematic area has to do with role management and traditional RBAC (role-based access control). Often, organizations start off with the best intentions and establish just a few roles:

    • Admin
    • Employee
    • Customer
    • Partner

    The roles become more granular over time:

    Admin Employee Customer Partner
    SuperAdmin Employee - HR Customer - Platinum Support Partner - Support
    RegularAdmin Employee - IT Customer - Gold Support Partner - Implementation
    LightAdmin Employee - Sales Customer - Trial Partner - Temp
    AdminTemp Employee - Support Customer - Temp Partner - Marketing

    Before you know it, that “handful” of roles you started with has expanded into a tangled web, creating an administrative burden and taxing the systems whose rules rely upon them. CoreBlox has seen environments that have over 15,000 roles! In the IAM industry this is generally referred to as the dreaded “role proliferation” (cue Darth Vadar theme).

    Fortunately, there is a great alternative to RBAC. Our partner, Axiomatics, has pioneered the concept of Attribute-Based Access Control, also known as “ABAC”. The thought process behind ABAC is easy to understand: why create new data attributes to manage (e.g. Roles) when you can let the user data speak for itself?

    Organizations that already use CA Single Sign-On for web access control have a distinct advantage when it comes to implementing an ABAC approach. The Axiomatics Extension for CA Single Sign-On allows policy decisions to be made by Axiomatics’ ABAC-based engine. A simple yes/no response is returned to CA SSO based upon the user’s attributes. It just works, no coding necessary!

    Are you interested in exploring the benefits of ABAC for your organization? Download this new white paper: Making a Business Case for Attribute Based Access Control