Essentials for Integrating Identity
Businesses building digital solutions need to protect their apps against data breaches and meet difficult data privacy regulations. This needs to be done while continuing to deliver a great customer experience. It can be challenging for companies to understand how to achieve this, especially for organizations that need to scale to many global teams.
Modern application security includes the use of an identity and access management (IAM) system to externalize the difficult security work. All teams will need to know how to integrate with the IAM system and the technical best practices. This article will provide some recommendations on how to manage the risks when migrating to this type of system.
The OAuth Framework
These days security solutions are based on the OAuth family of specifications to provide modern industry-standard security capabilities for web apps, mobile apps and APIs. The result should be that you can scale security solutions across the following components:
- Authenticate users with one or more proofs of their identity
- Protect data in APIs via arbitrarily complex business rules
The authorization server defined in the OAuth specification deals with authentication and enables authorization so that many security solutions, or ‘flows,’ can be built over time. It’s the heart of any modern IAM system.
The Identity Team
Identity is an area that crosses many disciplines. When building your IAM system, it is recommended to define roles that will work together to identify and manage key requirements.
Usually the product owner, user experience designer and InfoSec officer have part-time roles, whereas building and operating the IAM solution will be a full-time job for the other team members, such as the system’s architect and others described below.
Implementing IAM solutions can be quite expensive, and this role ensures there is a project sponsor. The product owner can be a decision-maker on features and prioritization. Important business questions around the company road map are also provided by the product owner, such as which countries the company will be expanding to and when.
User Experience Designer
Sign-up and login are usually the first impression your end users and customers have of your apps. OAuth-based solutions use login screens that are external to the app, so it’s important to make sure they look and feel like the app itself.
The UX team member will help ensure that this does not result in any blocking issues that could cause users to get confused and be unable to complete the login process, and may set requirements such as these:
- Users must be able to onboard to your app(s) in a smooth way.
- Valid users must be able to sign in, perhaps with passwords initially.
- There must be different branding in login screens per product.
- Users must be able to recover their password if they forget it.
- Users must not need to continually type passwords on small mobile keyboards.
This role will have its own requirements, some of which may originate from business partners and some of these may conflict with UX:
- Monitoring compliance and data privacy policies, such as GDPR.
- Ensuring that security events such as authentication attempts are audited.
- Reports must be available on who has accessed or changed which data.
- Passwords must be rotated and meet your company’s policy.
- Users must re-authenticate after a defined time period.
It is recommended to get onboarding and authentication strength agreed with InfoSec stakeholders early. This sometimes leads to spikes into login options that are both secure and usable, such as WebAuthn.
The IAM architect will plan the longer-term OAuth architecture. Depending on business requirements and the existing architecture, this might focus on capabilities such as:
- Securing data across a platform of OAuth-secured microservices.
- Designing how to manage data across legal boundaries.
- Ensuring that the most secure flows are used in web and mobile apps.
The architect will also work on shorter-term objectives, to ensure that old and new components can interoperate and that there are no blocking issues in areas such as UX or compliance.
The DevOps role can often work similarly to a second architect to help define non-functional requirements, some of which involve the authorization server:
- It must support features needed to integrate with monitoring systems.
- There must be zero-downtime upgrades.
The DevOps team member will work closely with developers on deployment of the authorization server and OAuth-secured apps.
OAuth solutions require additional HTTPS endpoints, data and configuration. It is ideal to have a couple of strong developers with skills in the following areas on your identity team:
- Separating concerns
- Reliable programming
- Crypto and SSL
It is common for developers to first implement OAuth flows into small proof of concept (POC) apps to avoid introducing technical risk into your flagship apps. Developers will typically also operate the authorization server in early stages of the deployment pipeline.
These days testing is usually itself a development role with a focus on automation. The tester will work with other developers to sign off on requirements:
- Some manual testing to ensure that the team have delivered a good UX.
- Verifying that data is secured correctly via test clients that call APIs.
- Login automation via UI testing frameworks.
- Working with DevOps on infrastructure testing.
- Ensuring that the system supports a projected load, agreed with the product owner.
In the early days, many companies cannot accurately articulate their IAM requirements, since the team is still learning. It is recommended to maintain a requirements list and to avoid fully committing to a particular authorization server until you are sure it meets your needs.
Choose an IAM Provider
The authorization server is developed by a vendor company that specializes in security. There are free open source options, however many companies use a paid option to receive both commercial support and application guidance. Once chosen, the system is hosted alongside APIs. These are the most common deployment options:
|IAMaaS||Use a system that is hosted for you as a managed service provided by a cloud vendor. You will not need to manage your own servers, and upgrades will be automatic, but it is still required to manage application configuration and OAuth data over time.|
|CaaS||Use a system that you deploy yourself, most commonly using containers, then deploy to a cloud native platform such as Kubernetes. This may provide greater control over behavior, but may also require more work, including managing upgrades of the vendor software.|
Requirements are the same regardless of which option you choose, and the identity team is still needed. Deployment convenience often needs to be traded off against other factors:
- Can the architect secure apps in the preferred way?
- Does the InfoSec officer have the auditing expected?
- Can the login UX be customized as required?
The architect and developers should aim to keep application code portable, based on OAuth standards. This will make it easier to switch to a different provider in the event of problems with your initial choice.
Release To Market
The identity team may produce many requirements and a backlog of future work. It will also use a scheme, such as MoSCoW, to prioritize these tasks with the product owner. Aim to run a real app against the production IAM system fairly early.
Identity Team Iterations
Once the IAM system has gone live, there are likely to be a number of iterations where the Identity Team continue to provide value:
- OAuth for single page apps (SPAs)
- OAuth for mobile apps
- Migrating personally identifiable information (PII) to pseudonymized alternatives
- Operational hardening
Once the difficult foundational work has been done, the identity team must provide guidance to other teams on how to integrate with the IAM system. This will include documentation on the tricky areas, so that other teams can migrate their apps productively and with low risk.
Once the IAM system is widely adopted, a full-time identity team may no longer be needed, though they are likely to remain the identity specialists within your organization. They can be consulted or informed whenever a new type of security solution is built.
When first integrating your apps with an IAM system, there is a learning curve to identify and meet the important requirements. It usually makes sense to form an identity team from a variety of roles, so that all important concerns of your business are addressed.
At Curity, we solve complex identity problems all day every day, and we know it can be hard. We’ve developed a range of resources to help you integrate identity into your organization: