AWS Developer Blog

New Support for Federated Users in the AWS Tools for Windows PowerShell

by Steve Roberts | on | in .NET | Permalink | Comments |  Share

Starting with version 3.1.31.0, the AWS Tools for Windows PowerShell support the use of federated user accounts through Active Directory Federation Services (AD FS) for accessing AWS services, using Security Assertion Markup Language (SAML).

In earlier versions, all cmdlets that called AWS services required you to specify AWS access and secret keys through either cmdlet parameters or data stored in credential profiles that were shared with the AWS SDK for .NET and the AWS Toolkit for Visual Studio. Managing groups of users required you to create an AWS Identity and Access Management (IAM) user instance for each user account in order to generate individual access and secret keys.

Support for federated access means your users can now authenticate using your Active Directory directory; temporary credentials will be granted to the user automatically. These temporary credentials, which are valid for one hour, are then used when invoking AWS services. Management of the temporary credentials is handled by the tools. For domain-joined user accounts, if a cmdlet is invoked but the credentials have expired, the user is reauthenticated automatically and fresh credentials are granted. (For non-domain-joined accounts, the user is prompted to enter credentials prior to reauthentication.)

The tools support two new cmdlets, Set-AWSSamlEndpoint and Set-AWSSamlRoleProfile, for setting up federated access:

# first configure the endpoint that one or more role profiles will reference by name
$endpoint = "https://adfs.example.com/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices"
Set-AWSSamlEndpoint -Endpoint $endpoint -StoreAs "endpointname"

# if the user can assume more than one role, this will prompt the user to select a role
Set-AWSSamlRoleProfile -EndpointName "endpointname" -StoreAs "profilename"

# if the principal and role ARN data of a role is known, it can be specified directly
$params = @{
 "PrincipalARN"="arn:aws:iam::012345678912:saml-provider/ADFS"
 "RoleARN"="arn:aws:iam::012345678912:role/ADFS-Dev"
}
Set-AWSSamlRoleProfile -EndpointName "endpointname" -StoreAs "ADFS-Dev" @params

# if the user can assume multiple roles, this creates one profile per role using the role name for the profile name
Set-AWSSamlRoleProfile -EndpointName "endpointname" -StoreAllRoles

Role profiles are what users will employ to obtain temporary credentials for a role they have been authorized to assume. When a user needs to authenticate after selecting a role profile, the data configured through Set-AWSSamlEndpoint is used to obtain the HTTPS endpoint that should be accessed. Authentication occurs when you first run a cmdlet that requires AWS credentials. The examples here assume a domain-joined user account is in use. If the user needs to supply network credentials to authenticate, the credentials can be passed with the -NetworkCredential parameter. By default, authentication is performed through Kerberos, but you can override this by passing the -AuthenticationType parameter to Set-AWSSamlEndpoint. (Currently supported values for this parameter are Kerberos, NTLM, Digest, Basic, or Negotiate.)

After role profiles are configured, you use them in the same way you have used AWS credential profiles. Simply pass the profile name to Set-AWSCredentials or to the -ProfileName parameter on individual service cmdlets. That’s all there is to it!

The new support for federated access reduces the burden of creating IAM user accounts for your team members. Currently, the tools support federated users for AD FS and SAML. If you want to use federation with other systems that support SAML, be sure to let us know in the comments. For more information about this feature, and examples that show how SAML based authentication works, see this post on the AWS Security blog.