Helen will come back.
So let's talk now about the third identity am identity which is the I am all and I am role is a set
of permissions that grant access to actions and resources in each of us.
These solutions are attached to our role not to and I am a user or a group.
So they're not fixed and assigned to a specific user or to a number of users in a group instead of being
uniquely associated with one person.
Our role is intended to be assumable by anyone who needs it.
So an application needs that all the it can assume it if allowed a user needs that role that either
can as you meet if allowed a role does not have standard long term credentials.
So it's not like the user where you have to define password and access keys.
It's not like that.
So that all depends on STDs or temporary security credentials.
If a user assumes that all assumes are all temporary security credentials by it.
Yes as teachers are created dynamically and provided to the user doesn't have to be requested.
Yes roles can be assumed or used by any of the following.
It can be assumed by an user in the same account as the role can be seen by an user in a different account
as the role.
And it can be assumed by a web service offered by either the US like easy to.
What do you mean here.
If I have all that has access to x 3 whether it's one bucket or multiple buckets then I have an easy
to instance they can take up this role in order to write and read from the S3 bucket.
And also the role can be assumed by an external user.
What you mean by external user none.
I am a user which we referred to before as exactly the Federated users.
So it could be authenticate by external identity provide a service that is compatible with Sammul to
single sign on Active Directory to come to mind when we talk about something to or open ID connect I.
And that is with Federation when you are talking about Google went on Facebook Amazon and so on and
so forth or a custom built identity broker so a user in the same account in a different account an application
or a rope were in need of this web service or a federated user.
All these can assume are all in it.
Yes there are two ways to use or su.
The first one is in the I AM comes and I am user in your account using game console can switch to temporarily
use the permissions of the role in the console and that is one way to do the cross account access if
you are in an account there is a all in a different account to access and S3 bucket.
OK the trusting.
Get a count.
And this is the trusted account.
So you are a user here and there is a trust relation that trusting accounts said I am ok I trust this
account.
So this is account a this can be the trust thing is B I trust account a ok.
Now if there is a role here and there are permissions to this role to access and its three bucket for
instance in this account Fareed let's say this user has his own regular permissions and credentials
in account inside the country.
Can he at the same time assume the role.
The answer is no.
If he tries to switch and if he's allowed to switch to the old in the other account he temporarily loses
his permissions in account.
So you can't you are not combining Either you have your regular ones if you don't assume the role then
you have the permissions for that all but not both at the same time.
When he presumes the original role in his account account then he loses the permissions for the role
but he retrieves or recovers the permissions he had within a account.
So one way to switch or a similar role is through the game console when you switch.
And in this case the users will give up their original permissions and take on the permissions assigned
to them all.
As long as they are assuming the role when the user exits the role that their original permissions are
restored.
So that's one way to switch roles.
What's the other way the other way is to do programmatic access requests using that Seelye using the
tool for Windass partial or the API.
So you send in a request to assume the role an application or service offered by the areas like is it
you can assume a role by requesting temporary security credentials for a role with which they make programmatic
request to us and use our all this way so that you don't have to share or maintain long term security
credentials by creating music for each entity that requires access to that resource.
So I have a resource that's three buckets here and this is that all who whoever needs it can request.
We will look into that.
If we authenticated and allow then we will issue temporary security credentials Dawkins and the users
can then talk the talk take the talking assume that I'll do whatever they want and there is an expiry
time for that talking either before they exit or if it expires then they are denied access but all delegation
a user who assumes a role temporarily gives up his or her own permissions and the state takes on the
permissions of the role that we already mentioned.
When these are exits or stops using that all the original user permissions are restored.
No a question might come to mind.
I have in the example we gave account be an account and we said right and we had the user here and we
had the three buckets here and we had a role here.
There is a way to provide cross account access also through exactly through resource base policies.
So when should I use what is the advantage of using in the scenario a resource based policy as opposed
to a one of the things we said that when a user in an account assumes that all in a different account
cross account access then they temporarily lose their permissions in account.
But what if the requirement was that the user wants to go while he has an account a user with his permissions
wants to copy or download some files from here into an S3 bucket that they on here.
If you use that all they don't have any rights in account.
As long as they use the dogs so they can read files from the bucket and it can be but they cannot download
it to the bucket in a county a Why.
Because they don't have the permissions they either have their own permissions or they have the account
permissions.
Now how can I do such a scenario in that case use the resource based policies and not the I am wrong.
Unlike our user base policy or resource based policy specified who in the form of a list of account
IDs can access the resource.
So now we are talking about the principle and the resource base policies that would be attached to the
bucket in a can be gross account access with resource base policy has an advantage overall.
So you can do it the or all you can do it via the resource base plus the advantage of resource based
policy is with a resource that is accessed through our resource base policy they use are still works
in the Trusted account trusted.
Here is a trust thing is B and does not have to give up his or her own user permissions in place of
the role permissions so they don't have to swear permission to take on the role and give up their own
with resource base policy they can maintain their permissions in a county.
In other words the user continues to have access to resources in that trusted account.
At the same time as he or she has access to their sources in the thrusting account this is B and this
is a this is useful for tasks such as copying information to or from the shared resource in the other
account.
The disadvantage is that not all services support resource based policies so you cannot use them as
policy responses all the way because not all the services would allow you to do that.
So thats the flipside.
Okay.
In the near future we are going to talk about service rules when you create an AM road that will be
assumed by a service this is called the service road.
Enough said for now.
We'll take a break and we will continue and detail whatever wrongs are in the next lecture.
Elsie.