Shadowing Practice: Mini Project - Implementing a Simple Web Identity Federation Application - Learn English Speaking with Video

Welcome back and in this advanced demo series you're going to get the chance to build a really simple serverless application which makes use of Web Identity Federation. Now it's going to be a simple example but all of the products and techniques that you'll use will be equally as applicable for bigger more complex projects.

Now to be efficient we're going to start off by applying a CloudFormation template which will create some base infrastructure.

This is going to take some time to apply and while it's working away, I can step you through the architecture So you understand how it works step by step So go ahead and move to the AWS console You'll need to be logged in to an AWS account with admin permissions and make sure that you have the Northern Virginia region selected now once that's done. There's a link attached to this lesson for a one-click deployment So go ahead and click that link that's going to move you to the quick create stack screen Everything should be pre-populated All you'll need to do is scroll down to the bottom check the capabilities box and then click on create stack Now that's going to take a few minutes to create and while that's happening. Let's talk about Architecture now what we're going to implement looks complicated But it's not really what we have is a user Jenny and this user is going to use our serverless application Now the end goal is to access a private bucket Containing pictures of patches the wondercat and right now that's not possible because that bucket is private It has no public access So what you're going to be implementing is a system where Jenny loads a serverless Application which is hosted within an s3 bucket called the app bucket and this is going to be loaded through CloudFront now this application contains HTML which loads in Jenny's browser together with JavaScript which runs in her browser. This is the front end to the serverless application Now this HTML and JavaScript which I'll call the application from now on shows a sign-in box So Jenny clicks that and she's directed at Google which in this case is our identity provider So at this point Jenny's prompted to authenticate and if this process is successful Then a Google authentication token is returned and you can think of this as evidence that Jenny has authenticated It proves her identity Now as you know by now, you can't use AWS resources with anything but AWS credentials And so this auth token can't be used to access anything inside AWS including our S3 bucket containing our private cat pictures.

What we need to do is exchange this authentication token for AWS credentials which can be used to access AWS resources.

And to do this Cognito is used.

By this point you'll have configured Cognito to accept Google authentication tokens as evidence of identity.

and Cognito using an identity pool will then swap the token for temporary credentials by assuming an IAM role.

Now that these credentials exist they can be returned to Jenny and now that Jenny has temporary credentials the serverless application can use these to access the private bucket.

And all of this is done without any self-managed servers, without managing any identity infrastructure and it has no real base costs until you start using the system.

Now this might look complicated, but we're going to do it step by step.

Step one is the base infrastructure, which is what the CloudFormation template is doing in the background right now.

Specifically, it's implementing the first part.

So right now you're applying the template, and I'll refer to you as Bob.

And as you apply the template into the CloudFormation service, This creates a CloudFormation stack which creates the actual resources.

It's creating the application bucket and the private patches bucket as well as the CloudFront distribution that you'll be accessing the application through.

Now that distribution is not actually contained on this diagram because we won't be using it initially but we will be using it later on in the demo series.

Now it's also creating some custom resources.

Lambda functions which copy assets into these buckets.

So by the time the CloudFormation stack completes, you'll have the application bucket to load files from via a CloudFront distribution, but at this point you'll be unable to access the private patches bucket because it's private.

So the initial architecture that we're implementing is relatively simple, but we're going to extend it as we move through this demo series.

So let's quickly move back to the AWS console and check if the creation process has completed.

And if yours is still in progress, just go ahead and pause the video and wait until your stack is in Create Complete.

We can see the stack's moved into the Create Complete state, and if we click on the Resources tab, we'll be able to see all of the resources that have been created by this stack.

Now I want to check that a few of these resources have completed successfully.

So specifically, I want you to click in the search box at the top and type S3 and then open that in a new tab.

When you're at the S3 console, this will list all of the buckets that are in this AWS account, and specifically, I want you to look at the ones that start WebIDF.

If you look at those, you'll see that we have an application bucket, and we'll have a private patches bucket.

Now if you go inside this application bucket, you'll note that we have two files, index.html and scripts.js, and these form the web application.

These are what will load into your browser and provide the application functionality.

If we move back to the main S3 console and go inside the private patches bucket, you'll see that this contains three images.

If you open each one of these images in turn, you'll see that these are all pictures of patches the WonderCat, and it's useful if you become familiar with exactly what these look like for later in this demo series.

So open these up each one by one, and you'll see that they're all pictures of patches the Wundercat.

And currently these are private. They're not accessible unless you have permissions.

Now let's move back to the main AWS console.

This time, click in the search box at the top and type CloudFront and then open that in a new tab.

You'll see that you have one CloudFront distribution.

and that one distribution should be pointing at the application bucket as its origin.

Go ahead and click on this distribution to go inside and I'll want you to note down the distribution domain name.

So that's this box on the left.

Go ahead and click on the icon next to it to copy this into your clipboard and note this down somewhere safe.

This is the web app URL.

You're going to need this later on in the demo series.

Now at this point that's everything that I wanted you to complete in this stage of the demo series.

So go ahead and complete this video.

When you're ready you can go ahead and start the next stage of this demo series.

Welcome back to stage two of this demo series.

In this stage you're going to be configuring the Google Identity Provider.

This means you'll be creating a Google API project and some credentials which the serverless application can use to interact with the Google IDP.

Using this, the application can direct sessions at the Google IDP for authentication which will return the Google authentication token if this process is successful.

By the end of this stage you'll have this running, but, and it's crucial to keep this in mind constantly, this token cannot be used to interact with AWS resources.

That's what you're going to be fixing in stage 3.

So let's get started implementing this.

And for that we're going to need to move back to our desktop.

Now at this point I would recommend using the text based instructions for this demo series.

And this is linked to every video for this demo series.

So go ahead and open that now.

And the first thing that we need to do is to create a Google API project.

Any application which uses OAuth 2.0 to access the Google APIs must have authorization credentials that identify that specific application to Google's OAuth 2.0 server. So our serverless application will be using Google for authentication and so we need a way to identify our application to Google and that's what we're going to do next. Now in order to do this you're going to need a Google login. Now Gmail is fine so you can either use your existing Gmail credentials or you can create a specific brand new Google account. Both of those will work fine but the first step is to move to the Google API console. Now the link for this is attached to this lesson and included in the text instructions. If you're not already logged in you'll be prompted to sign in using your Google ID and if you don't have an account you can go ahead and create one by clicking create account. In my case I'll be using one of my existing Google accounts so I'll go ahead and sign in. Once you're logged in you'll see the Google APIs console and the first thing we'll need to do is to create a new project representing our application. So click on the select a project drop-down you probably won't have any projects at this point so you'll need to go ahead and click on new project. Now you might be provided with a random name for your project but go ahead and replace this and I suggest you call this pet IDF for pet ID Federation. Now it won't call your project what you put in this box it will instead give you a random project ID. That's fine we're just going to refer to this as pet IDF. So once you've entered that go ahead and click on create. Now this might take a few moments to finish creating and we just need to wait for Once that has finished we need to go ahead and click on configure consent screen.

So this is where we configure various different permissions and access rights of our application.

The first thing we need to select is whether this application that we're using is only catering to internal users.

So that's users of your G Suite organization or if you're making this accessible to external users.

So any user with a Google account and that's what we're going to do.

do so select external and then click on create. We want this application to be available to everybody in the world because it's that important. Now again we'll need to provide an application name so go ahead and enter pet IDF in the app name box and then you'll need to click in the user support email dropdown and select your Gmail ID. So go ahead and select that and then scroll down and we don't need to enter anything into any of these boxes except the developer contact information and in here you'll need to enter your email address so go ahead and do that. Once that's entered click on save and continue. We don't need to make any changes on the scope screen so scroll down to the bottom and click save and continue. We don't need to enter anything on the test user screen so again just go ahead and click on save and continue and then on the summary screen we can scroll all the way down to the bottom and just click on back to dashboard and that's the consent screen which has been configured. Now that we've configured that click on credentials on the menu on the left and this is where we're creating the API credentials that our serverless application will use to communicate with the Google identity provider. So to do that we need to click on create credentials and it's going to be an OAuth based application so we need to click on OAuth client ID. Now the application type that we're creating together is a web application so go ahead and click in the drop-down and select web application. Under name go ahead and replace the placeholder with pet IDF serverless app and then we're going to scroll down and then also on this screen we need to make one other change we need to add an authorized JavaScript origin. Now this serverless application is running from the app bucket but it's fronted by CloudFront to provide HTTPS capability so we need to enter the domain name associated with the CloudFront distribution into this authorized JavaScript origins box. So go ahead and click add URI and then we need to move back to the CloudFront console, open up this distribution and then copy the CloudFront distribution domain name into our clipboard, return back to this API tab and paste this into this box and once you've entered that scroll all the way down to the bottom and just click on create.

Now once this is created you'll be presented with two pieces of information.

You'll have your client ID and your client's secret.

Now we'll be using the client ID later in this demo series so go ahead and copy that into your clipboard and note it down somewhere safe but you won't be using the client's secret.

So while I have hidden this on my screen you don't need to worry about it you won't be using it.

So make sure you've got a note of your client ID and then just go ahead and click on OK.

Now that's everything that you need to do in stage two of this demo series.

So at this point we have the front end application bucket, we have the private patches S3 bucket with the sensitive CAT images and we've configured a Google API project as well as credentials for that project which our serverless application will use to interact with the Google APIs.

So that's everything required for stage two. By this point if we configured the serverless application files in the front end bucket Then our users could use the serverless application To authenticate with the google identity provider and get back a google auth token But we can't use this to interact with AWS That's what we're going to configure in the next stage, stage three of this demo series Welcome back to stage three of this demo series In this stage you're going to be creating the Cognito Identity Pool and it's the function of this identity pool to take the Google authentication token that you received at the end of the previous stage and then exchange this using an IAM role for temporary AWS credentials. So once this exchange has taken place these temporary credentials will be provided back to our web application and it's using these credentials that we're then going to be able to interact with the AWS resources. So Cognito identity pools need to be configured with one or more authentication providers and once configured it will exchange successful authentications with these providers for AWS credentials and as I mentioned a second ago this is done by assuming an IAM role and that's what you're going to configure in this stage of the demo series. So to do that we need to go ahead and move across to our AWS console. Okay so we're back at the AWS console and now we need to configure Cognito so it can be used to exchange the Google auth token into valid AWS credentials. So let's go ahead and move to the Cognito console. So type Cognito into the find services box and then open that in a new tab. Go ahead and move to that new tab and then depending on whether you've used Cognito before, what you see might look slightly different. What we need to do is to move to the menu on the left and we need to click on identity pools. Now depending on when you're watching this demo, you might see a notification to try out the new version of the Cognito user interface.

At the time of creating this lesson, this new version hasn't yet been finalised, so I'm going to stick to using the current version of the UI.

You should probably do the same.

Normally I do recommend trying the new version of the UI, but at this point the new version has not yet been completed, so we'll stick with the current version.

Now if you haven't created any identity pools before, then it's going to jump immediately to a screen allowing you to create a new identity pool.

If you have used this before, then you might see an option to create a new identity pool.

But in either of those options, you're going to end up on a screen allowing you to create a new identity pool.

So we're going to be creating a brand new pool and we're going to be calling it 'Pet IDF ID Pool'.

So go ahead and enter that in the identity pool name.

Now identity pools can deal with both unauthenticated identities and authenticated identities.

So an example of when you might use this is if you have a mobile application which needs to provide a certain level of access for customers who aren't signed in, maybe read-only access to a DynamoDB database table, then you can use unauthenticated identities. In our case we only want to allow authenticated identities to access our application. What we're going to do is to scroll down and expand authentication providers. This is where we configure the integration with the Google identity provider.

So to do that click on the Google+ tab and it will prompt you for your Google client ID and this is the value that you noted down in the previous stage of this demo series. So it should start with a random number and then at the end it should have apps.googleusercontent.com. So this Google Client ID is what's used to enable the communications between Cognito and the Google Identity Provider.

So go ahead and enter that and then click on create pool. Now how this works is that when our application receives a Google Authentication token it provides this to Cognito. Cognito assumes a role and based on this role assumption generates temporary security credentials.

Now the role which is assumed is configured at this point. So if we expand view details we'll see it's creating two roles. We have a role if we're using authenticated users and we have a role if we're using unauthenticated users. Now it's only the authenticated users that we care about so we'll be focusing on this role. Now we'll be updating the configuration of the role later.

at this point just go ahead and click on allow to create these roles and if everything's worked as expected you should be provided with an identity pool id it's this that's highlighted in red on my screen so just copy down between the speech marks and note this down somewhere safe once you've noted that down you can go ahead and click on go to dashboard so our serverless application will be passing in a google auth token to cognito cognito will be assuming a role and using that role's temporary credentials to access S3. So what we need to do next is update the permissions allocated to that role and make sure that it has sufficient access to the private S3 bucket.

To do that we're going to move to the IAM console so click in the services box, type IAM and then open that in a new tab. And once there go ahead and click on roles, scroll all the way down and you should see two Cognito roles.

So they should be called Cognito_ and then PetIDFIDPool and you should have Auth_Role and UnAuth_Role and we need to look at the Auth role.

So select Cognito_PetIDFIDPool Auth_Role.

Once you've located that, just go ahead and click on it.

Then click on the Trust Relationships tab.

This is what defines what can assume this role.

So the trusted identity is cognito-identity.amazonaws.com So it's Cognito which can assume this role.

Now it also has some conditions which restrict what can assume this role and the top condition is the one that we're focusing on and this ensures that only this identity pool is able to assume this role.

So this means that only requests which are coming into Cognito Using this identity pool are able to assume this role get temporary credentials and use those to access AWS and the only identities which are able to use this ID pool are the ones which are configured by our Application to use the Google identity provider. So we're creating this chain of trust between our serverless application The Google identity provider and then Cognito via this ID pool now on the permissions tab We currently have one inline policy and this determines what permissions the temporary security Credentials have when this role is assumed now We want to make sure that those temporary credentials are able to access our private patches S3 bucket now to do that We're going to add another policy and this was a policy created by the cloud formation template at the start of this demo series. So click on attach policies, into the filter policies box, go ahead and type private patches, and this should show the private patches permissions managed policy. And if we expand that it's pretty simple, it just grants list bucket and get object permissions on the webidf-patches private bucket. And this is the private bucket that contains the sensitive pictures of Patches, the Wonder Cat.

So we're going to attach this policy to this role, and this will mean that our serverless application is able to access this bucket.

So check the box next to this managed policy and click on add permissions.

Now, that's everything that you need to do in stage three of this demo series.

So now we've created the Cognito identity pool that's created two IAM roles.

and we've adjusted one of those IAM roles to grant permissions on our private S3 bucket.

100

So now we have all of the details required to configure our serverless application to utilise all of these different services. So the Google Identity Provider, Cognito and S3.

101

That's what we're going to be doing in the next stage of this demo series.

102

So when you're ready you can go ahead and move on to the next stage.

103

Welcome to stage four of this demo series.

104

And in this stage of the demo series, you have access to temporary AWS credentials.

105

So what we're going to do in this stage is configure the HTML and JavaScript, which are stored within the application bucket.

106

And we're going to add the necessary configuration so that this JavaScript, when running within our web browser, is able to access AWS resources.

107

So we're going to edit the HTML and the JavaScript so that they're able to interact with the Google identity provider, the Cognito identity pool, and then finally using those temporary credentials to interact with the private patches bucket.

108

So once this stage is over, you're going to have a fully functional web application, which uses web identity Federation.

109

Now let's get started configuring this.

110

And to do that, we need to move across to the AWS console.

111

So we're going to be updating the files which represent our serverless applications.

112

So the index.html and the scripts.js and we'll find those in the S3 console.

113

So move across to S3.

114

You need to locate the webidf-app bucket and move into this.

115

And inside this bucket we have the two objects.

116

We have index.html and we have scripts.js.

117

And we need to download both of those to our local system.

118

So select index.html and then click on download and you'll need to save that to your local machine.

119

Once you've done that, do the same for scripts.js.

120

So select it, click on download, and again save this to your local machine.

121

Now once both of those have downloaded, go ahead and open them in a text editor.

122

So now we have open index.html and scripts.js.

123

The index.html is the webpage that's loaded when you open the serverless application and it's also the thing which calls any of the functions contained inside scripts.js and this is the JavaScript which runs in your browser and interacts with the Google Identity Provider as well as AWS.

124

Now the first thing that we need to do is to update this HTML file and we have one placeholder that we need to change.

125

we need to specify the Google Sign-in Client ID.

126

So this is this long string and you should have noted down your Google Client ID when you created the credentials in the second stage of this demo series.

127

So go ahead and copy down your Google Client ID and replace this placeholder.

128

So in my case this is how mine looks and yours should look similar just with a unique part at the start of this Client ID.

129

So once you've updated that go ahead and save this file and this just means that the HTML contains the data That can be used to communicate with the Google Identity Provider. Now We need to replace some placeholders in the scripts.js file But it's useful at this stage just to understand how this HTML works. When the page is loaded There's a button which is displayed which redirects through to the Google Identity Provider So when you click on this button the page changes through to the Google IDP you perform an Authentication operation and then the Google authentication token is returned now I'll talk about the code which allows this to happen in a second But in addition to this we've defined two areas of the page Viewer and output and these areas of the page can be interacted with by the JavaScript So we can change the contents of both of these areas and it's these areas that our code will use to interact with the user Now moving over to this what happens when we click the sign in button is that we're prompted to sign in using the Google Identity provider and if that's successful what we get back in return is a Google identity token. So this is important we get back proof that our user has logged in using the Google identity provider.

130

Now what happens next is we take that identity token from Google and we use it to call Cognito. We provide Cognito with that identity token as well as the identity pool ID.

131

And using both of these pieces of information Cognito exchanges this authentication token for valid AWS credentials. So at this point we have valid AWS credentials which have been returned by Cognito and these are stored in the AWS.config.credentials. So now we've got the ability to interact with AWS We run this access images function and this is the function that connects to the S3 bucket and it uses those credentials The first thing it does is to make a connection with S3 Specifically to a particular S3 bucket and this is one of the placeholders that we need to change Then it does a list Objects on that S3 bucket and then for all of the objects in that S3 bucket it generates a pre-signed URL using that object as well as the credentials that Cognito provided and so the output of this is it will display Any of the objects contained within that S3 bucket even though they're entirely private And it does this using the temporary credentials provided by Cognito when we swap the Google auth token for these valid credentials.

132

So we need to go ahead and replace these placeholders within scripts.js and have highlighted where you need to do the replace.

133

So the first one is you need to replace the identity pool ID with your specific Cognito identity pool.

134

And you should have noted this value down earlier in the demo series.

135

Once you've done that, scroll down a little bit further and you'll need to replace this bucket placeholder with the bucket name of the private S3 bucket.

136

So to get this, move back to the AWS console and then go to the main S3 console. Click on the private bucket.

137

So that's the one that contains "patches private bucket" and then just go ahead and copy down the full bucket name from the top of the screen.

138

So copy that into your clipboard move back to the scripts.js file and make sure you've got this entire placeholder selected between the speech marks and just paste in your specific bucket name.

139

Now this will be unique to you because this is one of the ones that was generated by CloudFormation.

140

Now we're just going to scroll through make sure that all of the other placeholders are correct.

141

We only have those two so the bucket name and then the identity pool.

142

And once you've done both of these inside scripts.js then just go ahead and save that file Make sure that you've also saved index.html and then move back to the AWS console We need to be at the main S3 console And then we need to enter the app bucket and we're going to upload these updated files back into the application bucket So click on upload and then click on add files Select those two files that you've just edited, then click on open, and then once they're populated in this list, go ahead and click on upload.

143

Now once that's done, we're ready to access our web application.

144

Now we need to access this via CloudFront.

145

So I want you to go ahead and open the CloudFront console.

146

You might still have a tab open to this, if you don't, just search for it in the search bar at the top, and then open that in a new tab.

147

Once you're at the CloudFront console, just go into the distribution and copy down the distribution domain name into your clipboard.

148

This is the address that you're going to need to access the web application.

149

So once you've got that, go ahead and open that in a brand new tab.

150

Then what I want you to do is to open your browser console.

151

Now the way that this works depends on the browser.

152

In Firefox you'll need to click on tools and then browser tools and then Web Developer Tools. Once you open that make sure Console is selected and this will allow you to see exactly what the browser does so what the output from the JavaScript is. You can see at the moment that in my case it's blank but once I start interacting with the application you'll see exactly what happens. Now getting to the browser console can depend on the browser that you're using. In some cases you have to right click and go to console, in some cases it's inside the developer tools menu. In the case of Safari on Mac OS you need to go into preferences and enable the develop menu and once in there you can access the browser console. In any case you need to have your browser console open before we continue. Now what happens next depends on whether you're logged in to your Google Identity or not because if you are logged in then it will use single sign-on. In my case I'm not currently signed in with my Google ID and so all I see is a sign in with Google button. Now when I click this sign in button a number of things are going to happen. First I'm going to be prompted to log in to the Google Identity provider so this web application has been configured when I click this button to move to the Google ID provider. Now if you're already using a Google account then it can suggest your existing credentials. If I wasn't logged in using this session then I would be prompted for a username, a password and optionally if configured an MFA. But in either of those cases if I do this process if I authenticate then what What I'm going to get in return is a Google Authentication token.

153

This IDP is then going to move me back to my application and the application is then going to proceed to exchange this Google Authentication token for temporary AWS credentials using Cognito.

154

And what you're going to see in the browser console is this process occurring in real-time.

155

So you'll be able to see some information that's decoded from the Google authentication token.

156

You'll notice a status message saying that it's exchanging that Google token for AWS credentials.

157

Once that token has been exchanged, then a session is created to S3 using these temporary credentials.

158

Then it lists any of the objects inside the private patches bucket.

159

It uses that object listing to generate a set of pre-signed URL operations against S3 so it generates pre-signed URLs for each of those objects and then that HTML is returned to the browser and the browser renders those pre-signed URLs so what you'll see start appearing are any of the images inside the patches private bucket In this case we have three Now if you click on any of these images, what you'll see is that the URL for these images, in addition to containing the DNS name for the patches private bucket and the object name, it's also got authentication information encoded in the URL.

160

So it's a pre-signed URL and that's how we're able to access this private bucket.

161

Our web application is interacting with the AWS APIs using these temporary credentials, generating these pre-signed URLs and it's these pre-signed URLs which allow us to access these private images.

162

Now that's everything that I wanted you to do in this demo series. You've successfully implemented a simple serverless application. All that remains is to tidy up the account and remove all of the infrastructure that you've created. But that's something that we're going to do in stage 5 of this demo series. When you're ready, you can go ahead and start the next stage of this demo series.

163

Welcome back to stage five of this advanced demo series where we're going to clear up all of the resources that we've created.

164

Now make sure you've got the text instructions open for this lesson because they're going to make things much easier.

165

So first, there's a URL in the text instructions for the cloud resource manager.

166

So this takes you to the resource manager for Google.

167

Once you're there, go ahead and select the PET-IDF project and then click on delete.

168

You'll need to copy down the ID for the project and paste it into this box to confirm and once you've done that, click on 'Shutdown' Now this does delete this project after a number of days In my case it's going to be deleted in one month's time but you won't be receiving any charges for this it's essentially deleted So go ahead and click on 'OK' Next, move to the AWS console and then you'll need to go back to Cognito Then you'll need to go to 'Federated Identities' Once you're at 'Federated Identities' go into the 'Pet IDF ID Pool' Once you're inside there, click on Edit Identity Pool, then scroll down to the bottom, Expand Delete Identity Pool, and then click Delete Identity Pool, and you'll need to confirm that process.

169

Once that's done, go ahead and move across to the IAM console.

170

If you haven't got it open still, then you can search for it in the bar at the top, and move to that console.

171

Then go to Roles, and then you're looking for the Cognito_PetIDFIDPool role.

172

So you should have 2, auth_role and unauth_role So select both of those, scroll up to the top and then delete those roles You'll of course need to confirm that deletion so go ahead and do that and then delete the roles Once those roles have been deleted you can click on services, click on cloud formation And once you're at the cloud formation console you can select the web idf stack Click on delete and then click on delete stack And that will complete the process of removing all of the infrastructure that you've used as part of this advanced demo series.

173

So that's everything that you needed to do in this advanced demo series.

174

You've successfully implemented the architecture that's on screen now.

175

So I hope it's been enjoyable.

176

All of the techniques you've used and all of the products are equally as applicable with large, complex ID Federation projects.

177

and so what you've learned in this advanced demo series will be massively valuable to real world AWS usage and if you have any questions in any of the exams on Identity Federation. So at this point I hope you've enjoyed it. Thanks for watching. Go ahead and complete this video and I hope you'll join me in another advanced demo series.

✨ Recomendar Video

497 oraciones

Technical deep dive on Managed Instance for App Service | BRK102

Business EnglishUniversity StudentsWorking Adults

284 oraciones

How to Become Your Own ISP

Business EnglishUniversity StudentsWorking Adults

163 oraciones

Brand Identity Design Challenge - Part 2 - How to create a full Behance Portfolio project

Business EnglishUniversity StudentsWorking Adults

97 oraciones

Redis Crash Course - the What, Why and How to use Redis as your primary database

Business EnglishUniversity StudentsWorking Adults

13 oraciones

IOC & Dependency Injection in Spring Boot - Quick Breakdown !! #shorts

Business EnglishUniversity StudentsWorking Adults

158 oraciones

OWASP Top 10 Explained

Business EnglishUniversity StudentsWorking Adults

¿Qué es la Técnica de Shadowing?

Shadowing es una técnica de aprendizaje de idiomas respaldada por la ciencia, desarrollada originalmente para la formación de intérpretes profesionales y popularizada por el políglota Dr. Alexander Arguelles. El método es simple pero poderoso: escuchas audio en inglés nativo y lo repites en voz alta de inmediato, como una sombra que sigue al hablante con solo 1-2 segundos de retraso. A diferencia de la escucha pasiva o los ejercicios de gramática, el shadowing obliga a tu cerebro y músculos de la boca a procesar y reproducir simultáneamente patrones de habla reales. Las investigaciones muestran que mejora significativamente la precisión de la pronunciación, la entonación, el ritmo, el habla conectada, la comprensión auditiva y la fluidez al hablar, convirtiéndola en una de las metodologías más efectivas para la preparación del IELTS Speaking y la comunicación en inglés en el mundo real.

Técnica de shadowing: lee la guía completa paso a paso →

Shadowing Practice: Mini Project - Implementing a Simple Web Identity Federation Application - Learn English Speaking with Video

Technical deep dive on Managed Instance for App Service | BRK102

How to Become Your Own ISP

Brand Identity Design Challenge - Part 2 - How to create a full Behance Portfolio project

IAM 1

How I deploy serverless containers for free

TIA Portal 101: The Beginner's Guide to Starting a New Project

Design a File Upload Service Like a Senior Engineer

CS50x 2026 - Introduction

Best NextJS Folder Structures | Beginner - Intermediate - Advanced

Redis Crash Course - the What, Why and How to use Redis as your primary database

IOC & Dependency Injection in Spring Boot - Quick Breakdown !! #shorts

OWASP Top 10 Explained

Why This Video Is Great for Speaking Practice

Breaking Down Natural Speech Patterns

A Simple Shadowing Routine to Try

¿Qué es la Técnica de Shadowing?