If your organization supports SAML, you can let users who have been
authenticated in your organization, access the AWS Management Console without
having to have IAM identities and without having to sign in again. AWS provides
a single sign-on (SSO) endpoint (https://signin.aws.amazon.com/saml) that
accepts SAML assertions that are used to grant your users federated access to
the console. You can find info here.
In this blog, I will focus on PowerShell automation to setup Active
Directory, Active Directory Federation Service, configure the AWS roles etc. to
achieve end to end automation. Manual configuration of this is nicely explained
here.
Overview
1.
The user browses to your organization's portal
and selects the option to go to the AWS Management Console.
2.
The portal verifies the user's identity in your
organization.
3.
The portal generates a SAML authentication response
that includes assertions that identify the user and include attributes about
the user.
4.
The client posts the SAML assertion to an AWS
single sign-on endpoint. The endpoint uses the AWS STS AssumeRoleWithSAML API
to request temporary security credentials and creates a console sign-in URL.
5.
AWS sends the sign-in URL back to the client
with a redirect.
6.
The client gets the console sign-in and is
redirected to the AWS Management Console.
Prerequisites
·
Sign up for AWS and get the AccessKey &
SecretKey. You can find the info about AWS Account and Access Keys here.
·
Install PowerShell module from here. All the AWS tools for Windows are nicely
bundled as a single MSI. Setup instructions can be found here.
Call Initialize-AWSDefaults to setup the default AccessKey and SecretKey to
use.
·
Initialize the script variables, these variables
are used throughout the script.
#location
where makecert tool is present, you can find this tool part of Windows SDK
$makecertpath = 'c:\temp\makecert.exe'
$domainname = "sivadomain.com"
$netbiosname = "sivadomain"
#for
illustration password is hardcoded, best is to use Get-Credential
$password = ConvertTo-SecureString "Password123"
-AsPlainText -Force
·
Code to do prerequisite tests
if ( !(Test-Path -Path $makecertpath))
{
'makecertpath
should point to full path of makecert.exe'
return
}
if ((Get-Module
AWSPowerShell) -eq
$null)
{
'AWSPowerShell
is not installed'
return
}
if ((Get-AWSCredentials
-ListStoredCredentials |
Select-String 'AWS
PS Default') -eq $null)
{
'AWS PS Default
is not set. Run Initialize-AWSDefaults'
return
}
Install Active Directory
Start with Windows
Server base installation. I used Windows Server 2012 R2 to test it. The same
should likely work with earlier versions of Windows Server as well. ADFS 2.0 is
part of Server 2012 R2, you might have to manually install it.
Install-WindowsFeature AD-Domain-Services, DNS -IncludeManagementTools
if ($env:userdomain
-eq $env:computername)
{
Install-ADDSForest –DomainName $domainname
`
-DomainNetbiosName
$netbiosname `
–DomainMode
Win2012R2 –ForestMode
`
Win2012R2
–DatabasePath "C:\ADDATA\NTDS"
`
–SYSVOLPath
"C:\ADDATA\SYSVOL" `
–LogPath
"C:\ADDATA\Logs" -Force `
-SafeModeAdministratorPassword
$password
Restart-Computer
}
We will create a user
“test”, this is the user account we will use to test SSO. We will also create
two groups, AWS-Production and AWS-Dev and the user “test” is added to these
groups. Everyone who is a member of AWS-Production will assume the role
ADFS-Production in AWS, while the members of AWS-Dev will assume ADFS-Dev role.
We will be creating these roles later. The user “test” is added to both
AWS-Production and AWS-Dev groups. Because there is ambiguity, the user can
assume either of the roles at AWS, it will prompt which role to assume. This
highlights the generic case, if the user maps to a single role then the user is
assumed that role without prompting. The following script creates the
user/groups.
#Add
new test user, that will used for SSO
New-ADUser -Name test -AccountPassword
$password -EmailAddress
"test@$domainname" -Enabled $true
#Create
two groups and add test user to them
New-ADGroup AWS-Production
-GroupScope Global -GroupCategory
Security
New-ADGroup AWS-Dev
-GroupScope Global -GroupCategory
Security
Add-ADGroupMember -Identity
AWS-Production -Members
test
Add-ADGroupMember -Identity
AWS-Dev -Members
test
Install ADFS (Active Directory
Federation Service)
ADFS provides
simplified, secured identity federation and Web single sign-on (SSO)
capabilities for end users who want to access applications within an
ADFS-secured enterprise, in federation partner organizations, or in the cloud.
In Windows Server 2012
R2, ADFS includes a federation role service that acts as an identity provider
(authenticates users to provide security tokens to applications that trust
ADFS) or as a federation provider (consumes tokens from other identity
providers and then provides security tokens to applications that trust ADFS).
Script to install the
ADFS role. This also generates a self-signed SSL certificate for https.
Install-WindowsFeature Web-Server, ADFS-Federation, Web-Scripting-Tools
-IncludeManagementTools
Import-Module WebAdministration
#Add
user account for ADFS service to run
New-ADUser -Name ADFSSVC -AccountPassword
$password -Enabled
$true
setspn -a host/localhost adfssvc
$adfsname = "adfs.$domainname"
#Generate
Self signed Certificate
&$makecertpath -n "CN=$adfsname" -r -pe -sky exchange `
-ss My -sr LocalMachine -eku
1.3.6.1.5.5.7.3.1
$sslcert = ,(Get-ChildItem 'Cert:\LocalMachine\My' `
| Where-Object { $_.Subject -eq "CN=$adfsname" })[0]
$cred = New-Object System.Management.Automation.PSCredential `
("$netbiosname\ADFSSVC", $password)
Install-AdfsFarm `
-CertificateThumbprint
$sslcert.Thumbprint
`
-FederationServiceDisplayName
"Sivas ADFS" `
-FederationServiceName
$adfsname `
-ServiceAccountCredential
$cred `
-OverwriteConfiguration
Establishing Two Way Trust
The enterprise ADFS
server should trust Amazon and likewise AWS (your tenant) should trust your ADFS.
Only then ADFS will send the claims and AWS will accept them. Command to
configure ADFS to trust AWS is:
Add-ADFSRelyingPartyTrust -Name "Amazon" `
-MetadataUrl
https://signin.aws.amazon.com/static/saml-metadata.xml
Now that ADFS trusts
AWS, we will establish the other side of the trust. For that you need to get
the ADFS metadata and create an IAMS SAML provider (with this document). The ARN
for the created SAML provider is saved in a variable. The account number is
extracted from this ARN. These two variables are used later in the script.
#Download
and save the ADFS metadata to a tempfile
#Because
of self signed, need to disable the SSL Validation
# otherwise WebClient.DownloadFile will fail.
$url = "https://localhost/FederationMetadata/2007-06/FederationMetadata.xml"
$metadatapath = [IO.Path]::GetTempFileName()
[Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
$webClient = new-object System.Net.WebClient
$webClient.DownloadFile( $url, $metadatapath
)
#Register
a new SAML Provider with IAMS that has this ADFS information
$role = New-IAMSAMLProvider -Name
"ADFS" -SAMLMetadataDocument
(cat $metadatapath)
$account = $role.Substring(13,12)
del $metadatapath
Create AWS Role
You need to create one
or more AWS roles. This is the role that will be assumed by matching the
attributes of the incoming claim. In our case, we will be creating two roles,
ADFS-Production and ADFS-Dev. As described, all users who are part of the
AWS-Production group in the Active Directory can assume the ADFS-Production
role. Similarly for ADFS-Dev, Each AWS role is associated with two policies. a)
Trust policy that defines who can assume this role b) Access policy that
defines what access the impersonated user has.
#custom
replacement is used for $role, so don't have to deal with escape chars
$trustPolicy = @'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action":
"sts:AssumeRoleWithSAML",
"Principal":
{"Federated": "$role"},
"Condition": {
"StringEquals":
{"SAML:aud": "https://signin.aws.amazon.com/saml"}
}
}
]
}
'@
$trustPolicy = $trustPolicy.Replace('$role', $role)
$accessPolicy = @'
{
"Version": "2012-10-17",
"Statement": [
{
"Action":
["s3:Get*"],
"Effect": "Allow",
"Resource": "*"
}
]
}
'@
New-IAMRole -AssumeRolePolicyDocument
$trustPolicy -RoleName
"ADFS-Production"
Write-IAMRolePolicy -RoleName
"ADFS-Production" -PolicyName "EC2-Get-Access"
-PolicyDocument $accessPolicy
New-IAMRole -AssumeRolePolicyDocument
$trustPolicy -RoleName
"ADFS-Dev"
Write-IAMRolePolicy -RoleName
"ADFS-Dev" -PolicyName "EC2-Get-Access"
-PolicyDocument $accessPolicy
Configure Assertions for the SAML Authentication Response
After a user's identity
has been verified, ADFS must send an authentication response to the AWS
endpoint (https://signin.aws.amazon.com/saml). This response must be a POST
request that includes a SAML token that adheres to the HTTP POST Binding for SAML 2.0 standard, and that contains the following elements. All
of these elements are required. You can find more info here.
Subject and NameID.: The following excerpt shows an example. Your
own values would substitute for the marked ones. The value of the Recipient
attribute inside the SubjectConfirmationData element must match the AWS
endpoint (https://signin.aws.amazon.com/saml), as shown in the following
example.
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
_cbb88bf52c2510eabe00c1642d4643f41430fe25e3
</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2013-11-05T02:06:42.876Z"
Recipient="https://signin.aws.amazon.com/saml"/>
</SubjectConfirmation>
</Subject>
PowerShell code fragment
$nameId = @'
@RuleTemplate = "MapClaims"
@RuleName = "Name ID"
c:[Type ==
"http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
=>
issue(Type =
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
Issuer = c.Issuer,
OriginalIssuer = c.OriginalIssuer,
Value = c.Value,
ValueType = c.ValueType,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"]
=
"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");
'@
RoleSessionName: An attribute with Name set to
https://aws.amazon.com/SAML/Attributes/RoleSessionName. The attribute value
provides an identifier for the AWS temporary credentials that are issued for
SSO and is used to display user information in the AWS console. This value must
be between 2 and 32 characters long, can contain only alphanumeric characters,
underscores, and the following characters: +=,.@-. It cannot contain spaces. For
example,
<Attribute Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName">
<AttributeValue>name
</Attribute>
PowerShell code fragment:
$roleSessionName = @'
@RuleTemplate = "LdapClaims"
@RuleName = "RoleSessionName"
c:[Type ==
"http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer == "AD AUTHORITY"]
=>
issue(store = "Active Directory",
types =
("https://aws.amazon.com/SAML/Attributes/RoleSessionName"),
query = ";mail;{0}", param =
c.Value);
'@
Role. An attribute with Name set to
https://aws.amazon.com/SAML/Attributes/Role. This attribute contains one or
more AttributeValue elements that list the IAM role and SAML provider that the
user is mapped to in your IdP. The role and provider are specified as a
comma-delimited pair of ARNs, in the same format that they are used for the
RoleArn and PrincipalArn parameters that are passed to AssumeRoleWithSAML. The
attribute must contain at least one role/provider pair, and can contain
multiple pairs. If the attribute contains multiple pairs, when the user uses
WebSSO to sign into the AWS Management Console, he or she is asked to select
the role to assume.
<Attribute Name="https://aws.amazon.com/SAML/Attributes/Role">
<AttributeValue>arn:aws:iam::account-number:role/role-name,arn:aws:iam::account-number:saml-provider/provider-name
<AttributeValue>arn:aws:iam::account-number:role/role-name,arn:aws:iam::account-number:saml-provider/provider-name
</Attribute>
PowerShell code fragment:
#list
of AD groups is first stored in a temporary variables
$tempVariable = @'
@RuleName = "Save AD Group Into
http://temp/variable"
c:[Type ==
"http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer == "AD AUTHORITY"]
=>
add(store = "Active Directory",
types =
("http://temp/variable"),
query = ";tokenGroups;{0}",
param = c.Value);
'@
$roleMapping = @'
@RuleName = "Role mapping"
c:[Type ==
"http://temp/variable", Value =~ "(?i)^AWS-"]
=>
issue(Type =
"https://aws.amazon.com/SAML/Attributes/Role", Value =
RegExReplace(c.Value, "AWS-",
"arn:aws:iam::$account:saml-provider/ADFS,arn:aws:iam::$account:role/ADFS-"));
'@
Now that the rules are
stored in script variables, the following code will create the claim rules in
ADFS.
$roleMapping = $roleMapping.Replace('$account', $account)
$ruleset = New-AdfsClaimRuleSet -ClaimRule
$nameId,$roleSessionName,
$tempVariable,
$roleMapping
$issuanceAuthorizationRules = @'
@RuleTemplate =
"AllowAllAuthzRule"
=>
issue(Type =
"http://schemas.microsoft.com/authorization/claims/permit",
Value = "true");
'@
Set-ADFSRelyingPartyTrust -TargetName
Amazon -IssuanceTransformRules
$ruleset.ClaimRulesString
-IssuanceAuthorizationRules $issuanceAuthorizationRules
Testing
Now you are ready to do
the testing! I had issues with IE, so I used Opera. Open Opera and invoke https://localhost/adfs/ls/IdpInitiatedSignOn.aspx from your ADFS server (you need to specify the
ADFS server name, if trying remotely). Note: You need to use the user “test” to
try this out. This is the user that was added to the appropriate groups.
References
You can find the code under
“AWS” folder at https://github.com/padisetty/Samples.
Explore & Enjoy!
/Siva
No comments:
Post a Comment