IAM Identity Center (ex AWS-SSO) and IAM 

There are two AWS services you can use to federate your users into AWS accounts and applications: AWS IAM Identity Center (the successor to AWS SSO) and AWS Identity and Access Management (IAM).

AWS IAM Identity Center is a good method to define federated access permissions for your users based on their group memberships in a single centralized directory.

AWS IAM Identity Center works with an Identity Provider (IdP) of your choice, eg Okta Universal Directory or Azure Active Directory (AD) via the Security Assertion Markup Language 2.0 (SAML 2.0) protocol.

If you use multiple directories, or want to manage the permissions based on user attributes, then AWS IAM may be a better option.

Note:

IAM Identity Center is the successor to AWS SSO or Single Sign-On. They both perform the same basica functionality, but SSO is now deprecated. However, SSO can still appear in the exam questions.

You have ONE LOGIN for all aws accounts in all aws organizations, as well as apps which are saml 2.o based and EC2 windows instances

The identity provider can be built in via IAM Identity Center or via a 3rd party Idp eg AD, OneLogin etc.

AWS IAM (Identity and Access Management) enables admins to manage access to AWS services and resources within an AWS account securely for what it calls “entities”.

Entities are IAM users created from the AWS IAM admin console, federated users, application code, or other AWS services. Admins can create and manage AWS users and groups directly, and utilize permissions to allow and deny access to AWS resources.

Differences Between IAM and IAM Identity Center

The difference between AWS IAM and AWS IAM Identity Center is that Identity Center manages access for all AWS accounts within an AWS Organization, as well as access to other cloud applications outside of AWS.

AWS IAM supports multiple identity providers per account.

AWS IAM Identity Center by contrast supports only a single identity provider.

This means that with AWS IAM, users need to log in to each AWS account and create a new role(s), or from one AWS account, Account A, create policies that allow a role to be assumed in another AWS account and to set the level of access to resources in Account B.

Using AWS IAM Identity Center, you can reuse existing AWS IAM Identity Center policies and permission sets. Policies and permission sets are defined at an organization level and are applied to groups or users at account level.

If the policies and permission sets already defined are not applicable to these new accounts, then you can create new ones via the AWS IAM Identity Center admin console.

AWS IAM Identity Center is ideal for managing multiple AWS accounts. An added plus of using AWS IAM Identity Center is that any new user added to a group will automatically be granted the same level of access as other members in the group, thus saving admin overhead.

AWS is now encouraging customers to switch from AWS IAM to AWS IAM Identity Center.

IAM Security Tools

IAM Credentials Report (at account-level):

you can generate this report to list all your account users and the status of their credentials

IAM Access Advisor (user-level):

to review policies

shows the service permissions granted to a user and when the services were last accessed

can tell you which resources are shared externally

eg
s3 buckets
iam roles
kms keys
lambda functions, layers
sqs queues
secrets manager secrets

one useful method is to define a zone of trust which can be your aws account or aws organization

and check for access outside the zone of trust. this is very useful to check for security problems

you create an “analyzer with a “zone of trust” in access analyzer

and then run the analyzer.

you will then see the findings displayed

Identity Federation

It lets users from outside of AWS to take on temporary roles for accessing AWS resources.

This is done by assuming an identity provided access role.

they use third party servers for login, and these have to be trusted by aws.

these then perform the authentication and provide the credentials for the user. ie 3rd party authentication: can be ldap, ms-AD, or SAML  single sign on or SSO, openID, Cognito.

the users can then directly access aws resources

this is known as identity federation.

An AWS user is an AWS identity created in the AWS IAM or AWS IAM Identity Center admin console. It consists of a name and credentials.

A federated user is a user identity created and centrally managed and authenticated by an external identity provider. Federated users assume a temporary role when accessing AWS accounts and resources.

A role is similar to a user, being an AWS identity with permissions and policies that determine what the identity can and can’t do in an AWS account.

However, instead of being associated with one person, a role is assumable by anyone who requires it and is permitted to use it.

A role does not have the standard usual long-term credentials such as password or access keys associated with it.

Instead, when a user assumes a role, it gives them a set of temporary security credentials valid for that session.

This allows admins to use roles to delegate access to users, applications, or services that wouldn’t otherwise have access to these AWS resources.

SAML Federation

SAML stands for Security Assertion Markup Language 2.0 (SAML 2.0)

this is for enterprises, who use eg AD or ADFS with AWS /SAML 2.0

it provides access to console or cli on aws temporarily

no need to create an iam user for these users

STS Security Token Service

AWS STS is an AWS service that enables you to request temporary security credentials for AWS resources. For example for IAM authenticated users and users that have been authenticated in AWS such as federated users via OpenID or SAML2.0.

You use STS to provide trusted users with temporary access to AWS resources via API calls, the AWS console or the AWS command line interface (CLI)

These temporary security access credentials function like standard permanent security access key credentials granted to IAM users. The only difference is that the life duration of the security access credentials is much shorter.

Usually an application sends an API request to a AWS STS endpoint for credentials. These access credentials are not stored by the user, but rather are created dynamically on request by STS. These STS-generated credentials will then expire after a short duration. The user can then request new ones provided they still have the permission to do so.

Once the generated credentials expire they cannot be reused. This reduces the risk of your resource access becoming compromised and avoids also having to embed security tokens within the application code.

The STS token lifecycle duration is set by you. This can be anything from 15 minutes to 36 hours.

AWS STS security tokens are generally deployed for identity federation, to provide cross-account access and to provide access to resources related to EC2 instances for other applications.

The STS token is valid for up to one hour by default.

ASsumeRole – users use a role within their own account for enhanced security, or alternatively for Cross-Account access to perform roles there.

AssumeRoleWithSAML – this returns credentials for users using SAML procedures

AssumeRoleWithWebIDentity – this returns credentials for users who are using an external IdP eg facebook, google etc

but note: AWS recommends NOT USING this but using Cognito instead

GetSessionToken is for Multi Factor Authentication for a user or aws root user

Most common use case for STS is to assume a role

so, you define an iam role within your account

define which principals ie users can access this iam role

then use STS to retrieve credentials and assume the IAM role you have set – the AssumeRoleAPI

they are valid for 15 mins to 1hr.

Identity Federation Use-Cases

AWS STS enables you to grant access to AWS resources for users that have been authenticated within your own on-premises network. This enterprise identity federation avoids having to create new AWS identities and no new login credentials are needed.

External web identities can be authenticated by a third-party online identity providers (Idps) such as amazon, google, facebook or other open-id connect compatible services.

This web identity federation method also removes the need to distribute long-term security credentials to enable access to your AWS resources.

Enterprise federation can choose between a variety of authentication protocols like SSO and it supports open standards such as SAML (security assertion markup language SAML2.0) with which you can use microsoft active directory federation services ADFS.

Alternatively you can also deploy SAML to build your own authentication service.

Many organisations maintain multiple AWS accounts and they can deploy IAM identities and cross-account roles to allow their users from one account to access resources located in another account. Once the permissions have been delegated to an IAM user, this trusted relationship can then be deployed to request temporary access via AWS STS login credentials.

Using a Custom Identity Broker App – this means enterprises and not SAML! exam!

If you dont have a compatible SAML 2.0 IdP you can use, or dont wish to use one….

then you can program your own custom id broker app. – this is outside AWS eg on premises

this is used to apply your iam policy

it then makes the request to AWS STS, which your users can then use to access AWS API or management console

Note: Identity Federation no longer appears as such in the exam. Instead, it now focuses on Cognito

AWS Cognito

Cognito provides federated identity pools for public applications.

to provide direct access to aws resources from the client side.

You log in to the fed id provider, get temp aws credentials back from the fed id pool, these come with pre-defined iam policy stating their permissions.

Example:

to provide temp access to S3 bucket using a facebook login – use federated identity pools (FIP) and aws cognito.

Note: there is also something called Web Identity Federation – this is an alternative to Cognito, but aws now recommends Cognito instead,

Our app logs into our iDp . in this case facebook login, then we authenticate with the FIP, this gets credentials from the aws STS, and sends them on to the app, which then can use them to access S3 bucket.

Cognito User Pools versus Identity Pools – the official AWS explanation:

User pools are for authentication (identity verification). With a user pool, your app users can sign in through the user pool or federate through a third-party identity provider (IdP).

Identity pools are for authorization (access control). You can use identity pools to create unique identities for users and give them access to other AWS services.

Cognito User Pools (CUP)

CUP creates a simple serverless database of users for apps

CUP then checks the database

Cognito User Pools and Identity Pools appear similar, but they have their differences. Consider what the outcome of the authorization process is in both cases.

CUP or Cognito User Pools provide a JSON Web Token which we use as an authorizer for an existing API.

With Cognito Identity Pools we receive temporary AWS credentials which we use to access AWS resources.

Another way of looking at it:

If you want to access AWS resources directly from the client side eg from a mobile or a web app, then use Cognito Identity Pools (CID).

In short, Identity Pool is a service that issues temporary AWS credentials to users who have authenticated themselves through an identity provider (IdP), which the Cognito Identity Pool has already established a trust relationship with.

CIP is NOT a user database service and it is NOT an identity provider (IdP) — even though its name is Identity Pool.

Both CUP and CIP “federate”, but for different purposes.

CUP — Getting a unified authentication token:

We can use Cognito User Pool (CUP) as our method to federate different identity providers (IdPs).

This makes your system behave in a standard way following the authentication process, no matter via which IdP a user signs in from.

The client receives tokens (id_token, access_token, optionally refresh_token) from CUP — but the client never gets a ‘federated’ IdP token.

With CIP issuing the AWS credentials is done by examining tokens issued from a different IdP.

We can use Cognito Identity Pool (CIP) to federate different identity providers (IdPs).

In this case the user authenticates with the IdP and obtains the token issued from them; it then sends the token to CIP to obtain the AWS temporary credentials.

Otherwise, use Cognito User Pools (CUP) instead.

If you need your users to access AWS resources (beyond API-Gateway / Appsync) directly, then you most likely want to use Cognito Identity Pool.

If you need a low cost, scalable authentication and user database service, then you will most likely want to use Cognito User Pool.