AWS Identity & Access Management

SoftwareOne uses SAML federated access to enable engineers to access AWS resources through a trusted Identity Provider (IdP) called Azure Lighthouse, which works with Microsoft Azure Active Directory. This eliminates the need for engineers to manage separate login credentials for AWS, making access more streamlined. Additionally, administrators can centralize user authentication and authorization management in the IdP, which improves security and ease of use.

The process of authentication involves the following steps:

1. The user logs into the Lighthouse (Azure AD), which confirms their identity and creates a SAML assertion with identity and authorization details.

2. The user is redirected to the AWS SSO endpoint without any noticeable action.

3. The user provides the SAML assertion to AWS, again without any noticeable action.

4. AWS verifies the user's authorization using the SAML assertion and the user's IAM role policies, without any noticeable action to the user.

5. If the user is authorized, AWS provides temporary security credentials for the user to access AWS resources via AWS Console.

Most of the process happens automatically and without user interaction.

When SoftwareOne engineers require write access to any environment, Azure's Privileged Identity Management is utilised.

Access is granted based on IT Service Management roles and can be traced to ITSM Incidents and Requests, providing visibility into the reason for temporarily elevating privileges.

All activity is recorded in your AWS CloudTrail and can be traced back to a specific SoftwareOne operator by name.

Diagram

Azure Privileged Identity Management (PIM)

Privileged Identity Management offers time-based and approval-based role activation to reduce the risks of excessive, unnecessary, or misused access permissions on valuable resources. The key benefits of Privileged Identity Management include the following:

• Provision of just-in-time privileged access to your account

• Assignment of time-bound access to resources with start and end dates

• Enforcing multi-factor authentication to activate any role

• Utilisation of justification to understand why users activate roles

• Receiving notifications when privileged roles are activated

• Conducting access reviews to ensure users still require roles

• Downloading audit history for internal or external audits

OpenID Federation (OIDC)

OpenID Connect (OIDC) is a secure authentication protocol that leverages the OAuth2 protocol for authorization. IAM OIDC identity providers are entities within IAM that describe external identity provider services that support the OpenID Connect standard, such as Microsoft Azure Active Directory (MS AAD). This authentication mechanism enables services to obtain secure programmatic access to AWS resources, eliminating the need to store long-term AWS credentials.

The process of authentication involves the following steps:

1. The service logs into the Identity Provider (such as MS AAD) and obtains an OIDC authentication token.

2. The service then requests temporary security credentials from AWS by using the AssumeRoleWithWebIdentity operation, providing the ARN of the IAM role it intends to use, and the OIDC token from the OpenID Connect identity provider.

3. AWS verifies the validity of the OIDC token and the identity provider's signature and checks if the service is authorized to use the specified IAM role.

4. If the request is valid, AWS provides the service with temporary security credentials, including an access key, secret access key, and session token.

5. The service uses these temporary security credentials to access AWS resources on behalf of the assumed IAM role. These temporary credentials have the same permissions as the role they were obtained from and are valid for a specific period of time.

Diagram