SAP-C02 Amazon AWS Certified Solutions Architect Professional – New Domain 5 – Continuous Improvement for Existing Solutions part 8

20. Web Identity Federation

Hey everyone and welcome to the Knowledge Poll video series. So in the past few lectures we have been discussing about federations, we had discussed more about Samuel in great detail. Now one of the important topics to understand specifically for the exams is related to the Web Identity Federation. And I am sure that in exams you will find some questions which is related to this specific topic. So let’s go ahead and understand what Identity Web Identity Federation is and why is it needed with a simple use case. So let’s take an example of a use case where you are designing a mobile application that allows users to play a quiz and depending on it, the scores are stored in the DynamoDB table and also in S three.

Now the application needs to be distributed via play stores and thousands of people will be downloading it. So a very common use case that you will find. So this specific mobile application is like a quizzing application and you play a quiz and the results of the quiz needs to be stored in the DynamoDB table and the S three bucket. Now the question is how will that mobile application store the results into those two AWS resources? Now, one of the simplest way that you might say is that use the AWS access and secret keys. However, one of the caveat you see whenever you design a mobile application, ideally you will be distributing it to play stores like Google Play stores, even Apple has its own Play stores. So thousands of people will be downloading that application.

And do you really trust storing the access and secret keys within that application? Because nowadays it is quite easy to reverse engineer the application and after reverse engineering the attacker can actually gain the access and secret keys. So that is one quite important challenge. So challenge is how will the application store data to the DynamoDB table and S three bucket? So simple solution was access and secret key, but that also possesses a great security risk. And in case you go ahead and you go ahead with access and secret keys, let’s assume that the access and secret key gets compromised. How will you update it with new keys to all the users who have already downloaded that application? And these are some of the challenges that you might face with mobile application which are dealing with AWS resources.

Now, in order to solve this, definitely you have to work with some kind of a temporary keys. So we have been discussing in the earlier lecture related to federation. So Federation is directly integrated with the Sts service which is responsible for temporary credentials generation. So until now we have been working with private identity providers like JumpCloud for federation related data. However, these will not help in the use case that we have been discussing like a mobile application use case. So in order to solve these kind of use case scenarios, AWS has a feature of Web Identity Federation which basically allows users to sign in through well known public identity providers like login with Facebook, login with Amazon, log in with Google, or any other open ID connect to generate temporary credentials.

So this is quite interesting. So I’ll just show you. So I’m sure if you’re into security, you have heard about security. Tube Vivek Ramchandran is one of the great inspirations who has really revolutionized the training industry of security. So if you go into his website, you see you have log in with Google.So this is something like federation. So users do not really have to log in with their personal IDs on the website, but they can use their Gmail credentials to log in. Similarly, in web Identity federation, what you can do is the mobile user, any mobile users who will be accessing, they will have to first login with the public identity providers like Facebook or Amazon or Google credentials.

Once they log in, they will get a temporary set of credentials and that temporary set of credentials will have access to store in the DynamoDB table and the s three bucket. So once the user authenticates against these identity providers, they will receive an authentication token which will be used to gain temporary credentials via the Sts service. So we have already discussed related to how the federation really works. But I’ll just give you a simple animated related scenario where you have a social media application over here you have an identity provider and you have the St service. So now what scenario is that? This mobile application wants to store certain data in the DynamoDB table which is running in the AWS.

Now, since the access and secret keys are not stored, what the organization has decided to do is they decided to work with web Identity federation. So this is the public identity provider of Facebook. So what user has to do is before they can play the quiz, they have to log in with one of the supported identity providers. So in our case, we’ll take an example of Facebook. So first the user logs in with the Facebook credentials. So these credentials will go to the identity provider of Facebook. Once the credentials are valid, the identity provider will give the AR token. So this is basically the authentication token.

So this token, once the mobile application receives from the identity provider this token, the mobile application will forward to the Sts service. Now, Sts service again has the mutual trust with the identity provider. We have discussed this flow in great detail in the earlier lectures. So Sts service will receive this token from the mobile application. It will verify whether the token is correct or not. If the token is correct, then the staff service will send a temporary access key, secret key to the mobile application. The mobile application in turn can use that set of keys to post the quiz results to the DynamoDB table and the S three buckets. So even if the keys are compromised, so these are temporary keys and these are user specific keys.

So it’s not like attacker reverse engineers a mobile application. He will be able to get the access and secret keys. It will not work that way. So this is the ideal way of designing things. Specifically, when you are working with such scenarios and in exams, they will give you certain scenarios, something very similar to this. And the right answer to that would always and always be Web Identity Federation. So whenever you see some kind of use case which deals with mobile apps applications, and that mobile application wants to interact with certain AWS resources, web Identity Federation is the right choice of answer in those scenarios. So this is it. About this lecture I hope this part has been understood by you.

21. AWS Cognito

Hey everyone and welcome back. In today’s video we will be discussing about AWS Cognitive. Now, although Cognitive is a service which is specifically used by the developers, one of the features of Cognitive is federation and this is one of the reasons why understanding the cognitive service is important as far as the exams are concerned. So let’s go ahead and understand the need of a cognitive service post which will understand various features. Now, on the definitive terms, AWS Cognitive basically provides authentication authorization and user management service for the mobile as well as web application. So let’s understand this with the use case. So let’s assume Andrew is a mobile developer in a startup organization.

Now, they have begun with a mobile wallet system and there are specific requirements which are listed as follows. Now, the first requirement is users should be able to sign in with the social network platforms like Facebook, Twitter, Google Plus and others. The second requirement is there should be a post sign up verification process with the help of one time password for the verification. Third requirement is account recovery feature should be present. So if someone loses the email address or I would say someone loses the password with certain kind of a hints, user should be able to fetch those details.

And there is one more requirement that a gift access must be allowed for the user to see the application. So now implementing these things actually takes a lot of time and Andrew must be wondering whether he should spend his time developing this authentication authorization system or should he spend time in making sure that a wallet system that he’s building is top notch and it is stable. So this actually is a use case. However, hundreds of developers across lots of organization are facing this kind of issue. So you take any web application. Now, one of the common things that you will find across most of the web application is the sign up sign in.

There is a forgot password page, you might have an MFA and you might also have sign in through Facebook, Twitter and various social networking platforms. So instead of developer building the same code again and again, copy pasting from various websites, instead of that, what AWS gave is AWS actually gave a feature which will implement all of these things with the help of Cognitive. So if you’ll see AWS, Cognitive provides authentication authorization as well as user management service for your mobile and web application. So now instead of Andrew developing all of these features, what he can do is he can simply reference to the Cognitive SDK within his mobile application and Cognito will in turn take care of all of these requirements as well as many more.

Now, at a very high level, Cognitive provides two major features. One is the cognitive user pools and second is the cognitive identity pools. Now, the Cognitive user pools take care of the entire authentication authorization process and the cognitive identity pool provides the functionality of federation for the users which are part of the user pool. So let’s not confuse ourselves with the theory. Let’s go to the Cognitive page and look into both of these categories. So I’m in the AWS Cognitive page and if you’ll see over here I have two options. One is manage user pools and second is manage identity pools. So if I click on manage user pools so currently there are no user pools which are created.

Let’s go ahead and look into what are the options when we create a user pool. Now first is you need to give the user pool name. Second is the username. Now within the username attributes you have various options like allow a sign in with verified email address, allow sign in with verified phone numbers, ETCA. So this is username. You also can select an email address or phone number. Now within the attribute there are certain attributes which you can select which user will typically have to put during the sign up process. Now within the policies you have the password strength policy. So what would be the password policy that would require? So if it is a wallet system you might need a minimum of maybe twelve character password where you have required numbers, special character, upper cases, lower cases and others.

Now along with that you also have a facility where you can have a password expiry related details. Now on the third column, this is a pretty interesting one where you can enable the multifactor authentication. Now the verification. So if a user puts in phone number you might want to verify whether the phone number actually belongs to him.So you can select email as well as phone number for the verification. So Cognitive will take care of sending SMS as well as verifying whether the email address or the phone number actually belongs to the user. Now along with that there are a lot of other features like message customization. You have devices list where you want to remember a user’s list or not and various others.

So if you will see these are a lot of important attributes which are generally required during the authentication, the authorization and also during the sign up process. So coming back to the PowerPoint presentation, I hope in a high level overview you understood what the Cognitive user pools are all about. Now think about a developer building those entire functionality by himself. It is actually a pain taking task. So now what developer has to do, he just has to use the AWS SDK and reference to the cognito and whatever policy associated with the user pool like MFA, the password policies, the expiration policies, all of those things will be taken by Cognitive.

Now, the second feature of Cognitive is the identity pool and this is something that we must remember for the certification exams also. So the cognitive identity pool which are also referred as the cognitive federated identities allows developer to authorize the users of the application to access various AWS services. So, we’ll understand this with a use case. So let’s assume that you have a quizzing based application in Android. Now, at the end of the quiz, when the user clicks on finish, what you want is that the result of those quiz should be stored within the DynamoDB table. Now, in order for the application to store the data in AWS service, there would be a need of certain access and secret keys.

Now, very first question that comes is you can hard code the access and secret keys within the application. Now, the problem with that is if someone reverse engineer, reverse engineers the application, he’ll be able to get the access and secret key. Now, the solution to this is the identity pool where AWS cognitive will give a federated access to the application, which is basically a temporary access secret keys which the application can then use to do various kind of operation, which for this example, it can be putting certain data in the DynamoDB table. So let’s quickly look the identity pool within the cognitive as well. So I’ll just click on Cancel if you will see over here, one is the user pool and second is the Federated identity.

So this is what the identity pool is all about. So if we’ll click on Federated identity, you have to give the identity pool name. You also have the option for various authentication providers. One is the cognito. So if you are using Cognito, you can specify the cognitive ID. You can let me quickly just you can also specify Amazon, Facebook, Google Plus, Twitter, open ID, Salmon, and even custom types. So let’s look into how identity pool really works. So, the overall working of identity pool is very similar to the web identity federation that we were discussing. So this is a user, the user signs into the mobile application. So this is a mobile application.

Now he signs it with a provider like Facebook or Google. So now the mobile application will coordinate with the IDP of that authentication provider. The IDP will send an authentication response. Now this authenticated response will be sent to the Cognato federated identities. Now cognitive Federated identities will verify this and it will coordinate with the AWS St service to generate temporary access, secret key and the token. Now this access key, secret key and token will be sent back to the mobile web application and then mobile application will use that access key, secret key and the session token to perform various operations. It may be on DynamoDB, it may be on Sri and various others.

So all of those things can be configured. Now, one last point that we should remember is the difference between a user pool and the identity pool. So I do remember is that the Cognito identity pool can take the identities from custom sources, it can take identity from cognitive user pool and it can even take identity from Facebook, Twitter, Google and various other platforms. Now it takes the identities and it will contact the Sts service. It will give back the access key, secret key and token. Through them, the various identity can access the AWS resources depending upon the permissions, which is.

22. SNS & Mobile Push

Hey everyone and welcome back. So today we’ll be speaking about a very interesting topic which I am sure most of you might like it, which is called as the SNS. So let’s go ahead and understand the basic about what SNS is all about. So SNS stands for Simple Notification Service and SNS is a fully managed message messaging and mobile notification service for delivering messages to the subscribe endpoints. Now, the concept goes very similar to what we had been discussing in the SQS as well, where you have a publisher on the left hand side and on the right hand side you have consumers and this is the SNS topic. So what happens is publisher will send a message to the SNS topic and SNS topic will forward that message to N number of subscribers which are subscribed to this specific topic.

Now, there can be various kind of subscribers which can be connected. You have Http, you have Lambda, you have mobile which can be push notification, SMS, you have email and many others. So let’s do one thing, let’s look into the practical session so that this concept becomes much more clear for us. So, I have a SNS topic which is created. Let me show you. This is the SNS dashboard and under this there is a SNS topic. So when I click on the ARN, this is the SNS topic. If you look into the protocol, I have three configured endpoints which is email, SQS and SMS. So what I have right now I have three configured endpoints over here subscribe to this SMS topic. One is email, one is SMS and one is the SQS. So let’s do one thing.

Let me click on Publish to topic. I’ll click here and it is asking me for a subject. The subject would be test and I’ll say this is our first SNS topic and I’ll click on Publish message. Now, if you might have heard, I got a notification in my phone. Let me show you. I’ll open this up. We’ll start with SMS first. And let me just quickly open if you see over here, I am not sure if you’re able to see, it says that this is our first SMH topic. If you are able to see, let me just put in more further and this is what it basically is all about. So this is all about the SMS part. We have three subscribed endpoints, one is SQS and one is email. So let’s do one thing. Let me go to SQS and let’s click on View and start pulling messages.

So we’ll start with the recent one. So this is the recent one and I’ll click on more details and you’ll see this is our first SNS topic. So this is the second one and the third one goes to the email. And in the email the subject would be the message subject that you had typed and the content is this is the first SNS topic. So what really is happening is that you create a topic in SNS. So this becomes a topic and whatever messages a publisher sends to this specific topic, the topic will forward the message to all the subscribed endpoints to this specific SMS topic. Now, there are various endpoints that you can subscribe to. Let me show you. When you click on Create subscription, you have protocol as http https email SQS you have application lambda and SMS.

So you’ll have to remember the protocols which are used or supported by the SMS. Now, it also supports push notification. And this is quite interesting because if you are not aware about what push notification is, I’m sure most of you might have gone through it. So in your mobile you might have seen that you get these kind of messages every now and then. So these are called as push notifications and you can send push notifications with the help of SNS as well. Now, this is it. About this lecture. In one of the organizations that I have been working with, what we actually had decided was that whenever there is an alert email, it should ideally go to WhatsApp. Because most of the people, they do not check email regularly, but they do check WhatsApp?