The Identity Providers section of IAM allows you to establish a trust connection between your AWS account and another identity provider (often referred to as an ID). Two standards are currently available:
SAML: SAML stands for Security Assertion Markup Language. Identity providers (IDPs) that use SAML include Active Directory and Okta.
OpenID Connect: This is another standard that is popular with Google and Salesforce.
Note that some IDPs support both SAML and OpenID Connect. For example, either standard can be used with Okta or Salesforce.
Establishing this trust involves first getting a metadata document from your IDP and uploading this document into the Configure Provider Wizard, as shown in Figure 9.4.
FIGURE 9.4 Configuring the IDP
Configuring an IDP is straightforward when using the Configure Provider Wizard. For the exam, the most important point to remember about IDPs is that AWS supports the SAML and OpenID Connect standards.
Under the Account Settings option of the IAM home page, there is a place where you can modify the password policy. This policy is applied whenever a user attempts to change their password.
AWS provides a default password policy for all AWS accounts, which includes the following rules:
The length of the password must be a minimum of eight characters.
The password must use at least three character types, including uppercase letters, lowercase letters, numbers, and a collection of special characters.
The password cannot be the same as the account name or the email address associated with the account.
Be familiar with the default password policy because you may be asked a question regarding whether the password policy needs to be changed to match specific criteria.
You can change the password policy, including implementing the following features:
Enable a default expiration of the account password.
Require the administrator to reset an expired password.
Allow users to change their own passwords.
Prevent users from reusing their passwords.
For the exam, recall that the ability for users to reset their own IAM passwords is not enabled by default.
As previously mentioned, when you create a user account, you have the option to create a key pair for authentication. One key is called the access key ID, and the other is called the secret access key. This is similar to a username and password in the sense that both keys are used to authenticate a user when the user needs programmatic access to their AWS account.
Immediately after the account is created, the key information is displayed, as shown in Figure 9.5.
FIGURE 9.5 Access keys
Keep this information secure and ensure that your users also keep this information secure. Note that you can download the key information in CSV format, or you can just copy and paste it to a secure location. If you lose this information, new keys need to be generated.
If a user loses their security keys or if the keys are compromised, you should deactivate the current keys and create new keys. You can accomplish this by going to the user’s account in IAM and clicking the Security Credentials tab, as shown in Figure 9.6.
FIGURE 9.6 Managing access keys
Your organization may include a policy to rotate access keys. This is similar to requiring that passwords be changed on a regular basis. AWS even suggests rotating keys on a regular basis, which you can see in Figure 9.6 where it states “As a best practice, we recommend frequent key rotation.”
AWS doesn’t provide an automated method of rotating keys, so you need to manually deactivate older keys and create new keys using this Security Credentials tab for each user. Alternatively, you can consider using a programmatic solution by creating a script that runs AWS CLI commands or creating a program in one of the languages supported by AWS SDKs. Creating this solution is beyond the scope of this book and the exam, but you should at least be aware of the viability of such a solution.