Building A Modern Line-Of-Business Application Part 4: Identity Management

Identity Crisis

Identity Management is often known as User Management. Security Management is often known as Access Management. A lack of common terminology is just one of the issues which makes this topic complex.

What is Identity Management? If you have ever built, or used, a multi-user, multi-interfaced software before, you've encountered it. Identity Management is used to provide security, access management, and business discipline to the users of your software.

Unfortunately, it is not always well thought out. Many developers rely on the built-in features of the database or O/S, and then find themselves boxed in and unable to change to something better or more flexible.

It is the key and firewall to your LOB (Line-of-Business) application. A good Identity Management system allows your application to avoid running into restrictions that may require difficult workarounds.

Security

Identity Management is commonly used for security. If your software merely checks for the username and password, you are already missing opportunities. For example, you could be making sure that the user is permitted to access the LOB software from a specific interface or device. Controlling access is no longer a yes-or-no process.

The security aspect of Identity Management must also include validating security tokens using them to expire old passwords, enforce user idle timers, and authenticate logging.

Access Management

Access Management is the more sophisticated side of security. It is all about what the user can do once they have been allowed inside. Many developers will equate this to "menu access" or in modern terms "role management." That's just a part of the story. Access Management should be designed to provide administrators complete control over what a user does, when it can be done, for how long, how much, and/or where it can be done.

One way to accomplish this is by establishing roles or groups. Roles provide the administrator the flexibility to keep things simple for most users while still allowing for complex adjustments where needed. This is how Microsoft ActiveDirectory works, even if it isn't the best designed example.

Business Discipline and Procedures

This may seem like an odd idea to single out, as it just seems like an obvious extension of Access Management. In its purest form that is correct. A developer would use a role to define whether or not the user has been granted access to a specific procedure or process. But your system can also define if a user can change information. Or perhaps, if they are required to answer additional questions when dealing with data. You could also use this system to define what and how specific users or interface will enter information.

The simplest example is assuming certain data (customer id, terms, credit limits, or available products) when working with a mobile device, while explicitly asking those questions from the user when working at a desktop. There are certainly people proficient in texting, but the general rule is that less typing is preferable when dealing with mobile.

Another example: A user is interfacing with the LOB data from within Excel. Roles can be used to restrict what they have access to and if the data is read-only vs read-write.

Identity Management is Not Employee Management

I've seen quite a few Identity Management systems use the same information as the Employee/Payroll systems. While this makes it easy to shut down a user's account when an employee is terminated, it doesn't give you the flexibility you need to add users who aren't employees.

You auditor needs access to reports, but his check comes from Accounts Payable. Your vendor may need to access their sales and inventory data but that doesn't mean he's eligible for your health insurance.

It also doesn't provide you the means to provide security and access management to specific devices. There are many different interfaces these days, both public and private, for roaming and physical locations. These types of controls are often overlooked.

We all have customer web portals to access your LOB data. There are many times when you need to provide employees access to customer web portal information. Using a central identity management system, which is not HR-based, you can provide access to customer information for the employee, as well as provide customer information to the employee.

Identity Management vs Interface/Device Management

Identity Management is more than "user credentials." Using an API-centric approach to development, you begin to see the bigger picture.

In the early days - and even now, in may shops - developers will look at the user as the primary qualifier of what data and programs are accessible. The user becomes the definer of how things are to be done. This is great for internal business applications, with the user in the office, at a desktop, with all of your intranet security in place. But what happens when the user is using the LOB software outside of this relatively uniform and protected bubble?

Do you want to provide "save as PDF" or "export data to Excel" features for accounting information when the user is at home? Do you want a user to access that data from outside at all?

Another place where this becomes important is with specific types of devices. This falls under "business discipline and procedures" more than under "security and access." Do you need to change the interface, presentation, and workflow for users accessing your LOB when in the warehouse, but give them full access when they are in the main office? What about mobile access?

What about the IoT (Internet of Things)? If you have a sensor transmitting data to your LOB, you probably don't want it interfacing with your web, GUI, or green screen. Linking the user identity as a device type of "sensor" will provide additional security because it won't have a "human" interface. Instead it might have a RESTful service or some other streamlined API.

Expanding user/password or user/password/device allows you to deny access to an authentication request that doesn't match all three.

Built-In Identity Management vs Application Identity Management

As I said at the top of the article, there is a natural tendency to use the built-in identity management of the database or O/S. This may not be the best solution.

The built-in systems are mainly used to address the security aspect of their one part of your infrastructure. They weren't designed to handle application access and security management. Nowadays, that simple login concept is too simple for restricting applications usage. It doesn't provide the flexibility you need when interfacing with your LOB application in a stateless interface, or when working with web applications, or anything non-persistent.

While I would recommend using the built-in system to interface security as a part of your process, I wouldn't recommend using it for user security. For example, if you are using an API from Excel, you can use the security to provide initial authentication and then do a secondary check using application identity management based on the user logged into Windows. If they both pass, then you can then request the user's identity.

This allows you to implement core security features based on the interface for features like ODBC or REST services that are built-in, and then layer additional security for the user's procedures. You get the flexibly to define user accesses for web interfaces, or other stateless interfaces like EDI and web callouts while still leveraging existing functionality. This style of identity management also allows a developer to hook into other centralized authentication systems, like ActiveDirecotory or OpenLDAP for role management.

In addition to external role management, it also allows the developer to interface with external login methods like biometrics (fingerprint readers and retina scanners) or single sign-on interfaces. When your company acquires another company, this sort of flexible thinking will make it easier to integrate their scheme with yours.

Consideration for Roles Management

It is really easy to build a system that can become very complex to manage. As your LOB application becomes more customized, developers may establish role after role arbitrarily. Then, in the future, managing or remembering what each of the roles do, and why, becomes troublesome. Discipline is key.

When a role is created, a developer should provide an explanation of what the role is used for, where it was used, and why it was created in both the role record, and within the application code. There are many times when a role will trigger some kind of override or additional access logic, and the user will need to see why they do not have access to do something. They will also need to know who has the access they need.

Another often overlooked feature of role management is remote authentication. There are many times when a supervisor needs to give access to an employee, but they are not physically present, or cannot be physically present for one reason or another.

A simple phone call to the supervisor should allow them to provide the proper authentication without giving away their password. A good way to do this is a simple mobile app that a supervisor can access to provide this authentication.

Prototype

A simple prototype of an Application Identity Management system would be:

USER.SECURITY

This would keep track of the user security information. Its only purpose is to authenticate the user with the LOB application. This would be a user specific settings needed for login.

Key: UserId
<1> = Encrypted Password
<2> = Date Create
<3> = Time Created
<4> = Password Expire Minutes
<5> = Idle Expire Minutes
<6> = Password Set Date
<7> = Password Set Time
<8> = Last Login Date
<9> = Last Login Time

INTERFACE.SECURITY

Interface security is used to provide access to specific interfaces, devices, and processes. It is not specific to a user, but could be. It is designed to provide independent security options based on type of interface instead of type of user.

Key: InterfaceId (ANY, TELNET, API, EXCEL, WEB)
<1> = Date Created
<2> = Description of what the interface is for
<3,n> = Inherited InterfaceId - Interface Id to use as the base settings, that this interface will be modifying.

SECURITY.ROLE

This role security is used to define what users and interfaces have access to. Each business process, screen, or API interface may have a RoleId here. This would define if the user has access to this role, or if the interface has access to this role.

Security Roles can inherit the settings from other roles. This provides a lot of flexibility, but also provides additional level processing.

Key: RoleId
<1> = Date Created
<2> = Description of Role
<3,u> = UserId
<4,u> = UserId Date Added
<5,u> = UserId Grant/Deny
<6,i> = InterfaceId
<7,i> = InterfaceId Date Added
<8,i> = InterfaceId Grant/Deny
<9,r> = RoleId to Inherit
<10,r> = RoleId Grant/Deny

API

AUTHENTICATE.USER.ID - This API would be used to authenticate a USER.ID.

Request:

USER.ID - The USER.ID to authenticate.

USER.PASSWORD - The USER.PASSWORD to use to authenticate.

INTERFACE.ID - The INTERFACE.ID that is being used to authenticate.

ROLE.ID - A ROLE.ID to check the USER.ID against.

Response:

STATUS - Evaluates to success, failure, or expired.

DESCRIPTION - A human readable version of the response.

TOKEN - An authentication token that can be used for stateless and non-persistent connections.

AUTHENTICATE.USER.TOKEN - This API would be used to authenticate a token either provided by AUTHENICATE.USER.ID or another token system.

Request:

TOKEN - The USER.ID to authenticate.

INTERFACE.ID - The INTERFACE.ID that is being used to authenticate

ROLE.ID - A ROLE.ID to check the token against.

Response:

STATUS - Evaluates to success, failure, or expired.

DESCRIPTION - A human readable version of the response.

GET.USER.ROLES - This API would be used to get a list of all the roles the user is part of.

Request:

USER.ID - The USER.ID to use in retrieving roles.

TOKEN - If USER.ID is not provided, then TOKEN should be so the application knows who made the request.

Response:

ROLES - List of all the roles (included inherited roles) for this user.

AUTHENICATE.USER.ROLE - This API would be used to check role access for a user. This would be done after the user has logged in.

Request:

USER.ID - The User Id to get roles for

TOKEN - If userID is not provide, then TOKEN should be so the application knows who the request is for

Response:

STATUS - Evaluates to valid, invalid, not authenticated, or override request.

DESCRIPTION - A human readable version of the response. On override request, display the reason for override and who can override.

Conclusions

Modern LOB applications aren't just about the data anymore. They are also about the APIs that the LOB provides. A developer needs to have an identity management system that provide the flexibility to handle not just data security but interface and procedures management.

Featured:

Jul/Aug 2016