Date: Tue, 19 Mar 2024 13:47:55 +0000 (UTC) Message-ID: <856187186.1223.1710856075872@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1222_1716376651.1710856075870" ------=_Part_1222_1716376651.1710856075870 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Core Scope and Requirements:
https://confluence.huit.harvard.edu/d= isplay/CLA/Common+Auth+Documentation
Requirements similar to Harvard's. We have 2 similar implementations, on= e for, primarily, researchers, and one for infrastructure (data center migr= ation):
In AWS an account owner provisions us= ers who will have access to the AWS console. Using AWS Identity and Access = Management (IAM) roles with specific levels of permissions can be assigned = to users by the account owner.
When provisioning an AWS account, a r= oot account is created. This account has access to do the highest level of = privileged tasks in the AWS console. It can delete the account, it can crea= te IAM resources and link other AWS accounts for billing purposes. If used = improperly, it can delete its own data centers. It is not advisable to use = this account unless absolutely necessary. However, AWS offers several ways = to integrate Identity and Access Management capabilities that allow console= users to operate with more granular privileges. In fact, many different SA= ML integrations are supported that allow for a multi-user console environme= nt where users operate with specific roles (https://do= cs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml_3rd-party.ht= ml).
An IAM role is similar to a user, it = is associated with a permission policy that describes what is can and can n= ot do in the AWS account. Roles can be a one to one or one to many associat= ion. It is easy to make simple rules that allow a role to do simple t= asks like launch and terminate EC2 instances or read from an S3 bucket. But= , it is also possible to make complex roles that limit a role to operate wi= th very specific privileges in a certain part of the environment. For examp= le, a role could be created for a developer team that would only allow thes= e users to operate in a specific dev-test "data center" (Virtual Private Cl= oud or VPC). Or, a role could be created that would only be able to spin up= certain size instances to ensure that spending doesn't get out of control.= An infrastructure role could be created such that only this group could be= able to perform typical infrastructure tasks like modifying subnets, VPCs = or load balancers configuration.
Integrating AWS IAM roles with campus= IdM is possible in many different scenarios. A common scenario might be th= e integration of a campus Shibboleth IDP with AWS. Each AWS account needs t= o have the IDP metadata configured in it. This can be accomplished manually= through the console or via the AWS API. The AWS account will require= the roles to be created in IAM with the level of privilege needed. This ca= n be done manually through the console or via API. More information on usin= g AWS IAM roles with Shibboleth can be found in this blog post: http://blogs.aws.amazon.com/security/post/TxRTTT5PLUE6B5/How-to-use-Shibbo= leth-for-single-sign-on-to-the-AWS-Management-Console.
In the simplest scenario, an IDP coul= d be configured to pull group memberships for a user that is logging into A= WS from an LDAP directory. One of the easiest ways to accomplish this is to= develop a naming scheme for IAM roles that contain both Amazon Resource Na= mes (the 12 digit number identifying the account) and a role.<= /p>
The IDP could be configured to look f= or LDAP groups with a certain regular expression string and parse that info= rmation into the attributes that AWS requires (awsRoles and awsRoleSessionN= ame). For example, inserting a person into a group named aws.123456789012.r= ead-only could inform AWS that the user is logging into account 12345678901= 2 and that the user should assume the IAM role with the name "read-only" in= that account. If the user is in multiple groups and multiple attributes ar= e asserted, the user has the choice of what account/role they wish to assum= e (see figure 1-1).
Example attribute resolver stanza= s for group naming convention in the form of "aws.123456789012.read-only"= span>
<resolv= er:AttributeDefinition id=3D"awsRoles" xsi:type=3D"ad:Mapped" source= AttributeID=3D"MemberOf"> <resolver:Dependency ref=3D"ldap"/> <resolver:AttributeEncoder <= span style=3D"color: rgb(0,0,0);"> xsi:type=3D"enc:SAML2String" name=3D"https://aws.amazon.com/= SAML/Attributes/Role" friendl= yName=3D"Role" />  = ;<ad:ValueMap> = <ad:ReturnValue>arn:aws:iam::$1:sa= ml-provider/Shibboleth,arn:aws:iam::$1:role/$2</ad:ReturnValue>= span> <ad:SourceValue>cn=3Daws.([^.]*).([^,]*),.*</a= d:SourceValue> &l= t;/ad:ValueMap> </res= olver:AttributeDefinition> <resolver:AttributeDefinition id=3D"awsRoleSessionName" xsi:type= =3D"ad:Simple" sourceAttributeID=3D"mail"> <= ;resolver:Dependency ref=3D"ldap"/> <resolver:At= tributeEncoder <= /span>name=3D"= https://aws.amazon.com/SAML/Attribu= tes/RoleSessionName" &= nbsp; friendlyName=3D"RoleSessionName" /> |
A caveat with the use of roles is tha= t roles do not support MFA. However, the institution could enforce MFA at t= he IDP or SSO layer. One of the obvious advantages of using IAM roles over = IAM users is that there are no credentials on the AWS side to manage. When = a user is taken out of the group or they leave the institution, they lose a= ccess to the AWS environment.
User is given login URL (in the case of AWS, it is an IDP initiate= d SSO handler in the form of https://idp.exampl= e.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=3Durn:amazon:webservices= )