“Account” is a slippery word. It’s a noun, it’s a transitive verb, it’s an intransitive verb. It slips into a number of idiomatic phrases.* And when it comes to AWS, it’s a misleading word.
It is important to separate the concept of access from the concept of an account. Since most people at Penn have a banking account, I will use the example of banking to separate the two concepts.
Let’s assume you have money in a checking account in a bank. The bank assigns an identifier to your account. If the bank is secure you are the only person who can add or remove money from your account. One process, authentication, confirms that you are you. A second process, authorization, determines that you are entitled to add or remove money from your account.
Authentication
You have an ATM card. When you put the ATM card in an ATM you are providing authentication that you are the person entitled to add or remove money from that account. As a precaution, the bank asks for a PIN as a second form of authentication. (That’s right, you’ve been doing two-factor authentication ever since you started using an ATM.)
Authorization
Independent of that authentication, the bank has authorized anyone who authenticates with your ATM card and PIN to deposit or withdraw money from the account.
It probably does not seem like an independent process, but it is. Suppose you subsequently get a savings account at the same bank. The bank will change your authorization so that you can access the savings account. However, nothing about authentication will change. You won’t have to get a separate ATM card for the savings account, and you won’t need to change your PIN. Your authorization changes, but your authentication stays the same.
Shared Access
What if you want to grant someone else access to your bank accounts? That person will be issued their own ATM card and they will have their own PIN. They are not you, so they should not authenticate as you. However, the bank will authorize them to have access to the same accounts that you have. In the world of Identity and Access Management (IAM), you and the joint account holder will have the same role.
AWS Authentication and Authorization
This is directly analogous to our Landing Zone at AWS. When you log in with your PennKey Username and Password you are authenticating—proving who you are. It’s the same process as when you access the PTO system or your benefits information.
What happens next depends on authorization. If you have been authorized to access an AWS account, you can. If you have not been authorized, you can’t. There are different levels of authorization, or roles. All accounts at Wharton start with two roles: ReadOnly and AdministratorAccess. It is possible to craft additional roles, and I’m sure that will happen.
For anyone who has already experimented or worked with AWS the Wharton setup will seem strange at first. Beginners with AWS start by creating their own AWS account. They create their own authentication with an ID and password. By default they have authorization to do add or remove anything in that account. They also manage all the security for that AWS account. They can grant access to their AWS account by creating something called an IAM User.
That system would not scale well to Wharton Computing, where scores of users need access to multiple resources in multiple AWS accounts. And Wharton’s system reduces the risk of accidental exposure. Resources in one AWS linked account are visible only to users who have been granted a role in that account.
* *“Give a good account of yourself,” “On no account,” “No-account,” “On your own account,” “On account of,” “By all accounts.”