Capturing SDLC Swim Lane Identities and Roles

Identity and Permission inventories first step towards understanding your identity and permission exposure. We want to create a common understanding of the identities and roles used by our systems.

Actors that reach out to other capabilities operate with an identity. Capabilities that are asked to do something on behalf of actors are configured to allow or disallow work requests based on the role that the Actor's identity has in the receiving system. Individual components may be operate as both Actors and Capabilities at different parts of their processing.

The principal of least privilege says that tasks execute with the minimum permission to do the work request. The simplest way to do this to isolate each actor by giving them their own identities. Each system contacted by the actors maintains an identity/role map that describes the identity's permissions in the receiving system.

The table at the right shows
  1. The identities of each actor in each SDLC environment
  2. The list of permissions/roles in each system and which identities have those permissions.
This talk describes a method for documenting the identities of the system components and the permissions granted to those identities This is useful for:
  • A common understanding of the environment
  • A document that facilitates communication between teams.

System Example

The system below has identities and some roles we want to capture.

Actors and their Identities: 
  1. The originating web service because the call the web service
  2. The web service because it accesses the secret store and sends data to the message queue
  3. The message queue reader because it accesses the secret store and sends data to the database
Roles and Permissions
  1. The web service uses the caller's role to determine if the the data POST is allowed.
  2. The secret store uses the web service's role to determine if it should allow access to secrets.
  3. The message topic uses the web service's role to determine if it is allowed to post a message.
  4. The message message reader's secret store uses the  message reader's role to determine if it has access to secretes, the database credentials.
  5. The database uses the client's role to determine if it can saves the message to the database.
The web service in this example is both a Capability and an Actor.  It has an identity and it associates roles with the identities of others.


This is a session that captures the identities and roles in the simple application above.

Sample Table

The Confluence table I created as part of the video.  It contains the discovered identities and roles. It has places to capture the information as we move through the SDLC.  Companies often require different identities or provide different capabilities in development and production.


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs