CompTIA CYSA+ CS0-002 – Service-Oriented Architecture part 2

4. REST (OBJ 2.2)

Rest. In this lesson, we’re going to talk about Rest, the representational state Transfer. Now, Rest is a software architectural style that defines a set of constraints to be used for creating web application services. When we talk about Rest, you also hear it referred to as Restful APIs. And these are a looser architectural framework than Soap’s tightly specified protocol. Now, if you remember we talked about Soap used XML based messages. Well, Rest has a lot more options. Rest is going to support Http XML CSV, which is common separated value format, or even JSON messages. All of these are messages that can be accepted and passed over Rest instead of just relying on a properly format XML document like Soap does. Now, let me give you an example of how this all works.

If you wanted to go to My website and log into your account, you would go to the domain name of Deontrain. com and then go to the resource MyAccount. It would look like deontrain. com MyAccount now, when you do this, it performs an Http Get request to receive a list of all the courses you’re enrolled in. It’s also going to give you your progress or percent complete in the courses you’re enrolled in and some other basic profile information. Now, on the other hand, when you start taking a quiz on my site and you click the submit button at the end, it’s going to take that information as part of a Restful API command and use the Http post command to send that to my server. Now, as we go through this lesson, we’re going to talk a little bit more about Rest and Restful APIs. And we’re specifically going to talk about three major concepts.

We’re going to talk about Oath, we’re going to talk about OpenID, Connect or OIDC, and we’re going to talk about JSON, Web Tokens or Jot. Now, when we talk about Oath, this is a delegated authorization framework for Restful APIs that enables applications to obtain limited access, also known as scopes to a user’s data without giving away a user’s password. Now, when you’re dealing with Oath, this is a form of authentication and authorization using this Restful API. Now, when we talk about Oath, this stands for the Open Authorization to Protocol. It’s version two. Now, Oath comes in two versions. There’s version one, which is not commonly implemented anymore, and there’s version two. Now notice what I said there. It’s called oath because it’s the open authorization protocol. That means this is all about authorization, not authentication.

Now, when you’re using Oath, it’s going to serve four types of parties. You have clients, you have resource owners, you have resource servers, and you have authorization servers. Again, OAuth is for authorization. When we talk about a client, these are applications that the user wants to access or use. When we talk about the resource owners, these are the end users who are being serviced. When we talk about the resource servers, these are the servers provided by a service that the user wants to access. And then we have the authorization server. When we talk about the authorization server, we’re talking about servers owned by the identity provider or the IDP. Now how does this all work in the real world? Well, let me give you an example here. Here on the screen, you’ll see three columns. We have the client, the authorization servers, and the resource owners.

Now this example comes from Flickr. And this is assuming you’re going to be using the Flickr oath service. This is their version of single sign on. Now, when I talk about a client here, I’m not talking about a client as in an end user. Remember my definition. I just use an oath. A client is an application that the user wants to access or use. So let’s assume that my website was going to use Flickr single sign on as a way for you to log into it. If you wanted to get into my website, you would go to my website, the application, in this case, the client, you would click on the log in button and select the log on with Flickr. If you do that, you are now requesting a token. At this point, my server is going to communicate to the authorization server going from the client to the authorization server, and we are going to request that token.

At that point, the authorization server should give us back that token. They’re going to return it to us. Now that that’s happened, we’re going to direct the user to go to Flickr for authorization. So you’re going to get sent over to Flickr and you’re going to put in your username and password on the Flickr site. At that point, Flickr server, which again is the authorization server here, is going to prompt the user to provide their authorization, their username and password. Now if you have put in the right username and password, the resource owners in this case, which is the end user wanting to be serviced, in this case, you is going to authorize applications to have access. So you’re going to get a button that says from Flickr, says deontrain. com would like to allow you to log into their site using your Flickr account. And you’ll say yes or no.

At that point, you’re going to be redirected back from Flickr server, the authorization servers, to the application, that game or website, in my case, my website. And that way you’re going to get this oath verifier sent over. Now the client, again, my application, which could be a game or my website or something like that, is going to exchange the required token for an access token. Once we have that access token, we’re going to grant that access token over to Flickr to their authorization servers, and they’re going to associate that with your account. Now anytime you log in and try to log into my service or my application using, clicker it’s going to know what rights you have on my system. At that point, you’re going to have this oath token that’s now going to allow you to have protected access to different resources, maybe videos or quizzes or lessons or whatever it is.

And then I can send those over to you, the resource owner being the end user. That’s how this works. Now, this is a little bit different than what we talked about with Soap and Sam’l, but it kind of uses the same concept because Oath was based on those things. Now, when we talk about Oath too, it is vulnerable to some attacks. For instance, it is vulnerable to a cross site request forgery attack and also to open redirects. This is where the attacker is going to attempt to get you as the user to click on a link so your browser will perform the actions as that user using your credentials. And so you have to be careful of these things. And we’ve talked before about cross site request forgeries. Now of Two is explicitly designed to authorize claims and it is not used to authenticate users.

Notice this is an authorization protocol. Open authorization two. That’s what it stands for. So keep that in mind. OAuth is an authorization, not an authentication platform. Now that means if you wanted to use it, you have to have some way to authenticate users too. So how are you going to do that? Well, one of the most common ways is to use OIDC, which is Open ID Connect. This is an authentication protocol and it can be implemented as special types of OAuth flows with precisely defined token fields. This will allow OAuth to be used for the authorization, which is what it’s good for. And Open ID Connect can be used for authentication, which is what it’s best for. Now, I know I’ve been throwing around the words authorization and authentication over and over again in this lesson and some previous lessons.

And if it’s been a while since you’ve done security plus you may not remember what the difference is between these two. So let me just go ahead and take a pause here and tell you exactly what that means when we talk about authorization. This is the function of specifying access rights and privileges to certain resources. So if you want to access this video lesson in the course, you need to have authorization to do that. For instance, if you want to take this Friday off of work, you need authorization from your boss to not show up. They have to give you permission. Now, if we look at authentication, this is the process of verifying the identity of a person or device. So when you go to my website and you put in your username and password, that is authentication.

Once you do that and we know who you are, we then check what courses you’re in and based on those courses, you have the authorization to access those videos. If you’ve signed up for this course you have the authorization to watch the CYSA videos, but if you didn’t sign up for the pen test plus course you can’t watch those, you’re not authorized. But you use the same authentication to get into the system for both, right? And so that’s the difference here. Now when we talk about OAuth, this must be paired with another tool to perform that authentication because you have to have a way to verify that identity. And again, the best way to do that is with open ID connect. It’s one of the most popular ways of doing this. Now the third thing we need to talk about is JSON web tokens.

Now when you see JWT, which stands for JSON web Tokens, this is actually pronounced as Jot, like J-O-T but it is JSON web tokens. Now this is a token format that contains a header, a payload and a signature in the form of a JavaScript object notation message, which is a JSON message. Now when you think about a JSON web token, I want you to think about OAuth. These are used to provide authorization and specify what access rights and privileges a user would have on a system. Again, these are a form of assertion that’s being made about the person and it assumes that person has already been authenticated. So if you’re using a JSON token you’re making assertions. This again is the authorization piece, not the authentication piece.

Now if you want to see what a JSON web token looks like, it looks something like this. Notice you’ve got some curly brackets and we have these different key pairs together. ALG H. Two, five, six. What do you think that means? That’s an algorithm, what algorithm we’re going to use to hash this and make sure it has integrity. In this case H two five six, which means Shaw 256. It says what type it is. In this case a Jot, a JSON web token. Then you see the next set we have sub, which is the subject. Who are we talking about, what’s the ID of that person? Then we have the name, in this case Jason. We have the email, in this case support at Dion Train. Now these are just two fields that are attributes of that subject. Whoever that ID string is, in this case it’s Jason. With support@deontrain. com we can have lots of different fields in this, but in this case I wanted to keep it simple and just show you the basics. And this would be a very, very simple Jot. Now if you want to send this Jot over to a web server, how can you send it? Well, just like we were using with Soap and Sam’l, where we can put it in as part of the URL, we can do the exact same thing. Here you’ll see Deontrain comauthorized, question mark and then all that stuff in white, which is essentially base 64 encoding. We take that, Jot. We encode it using base 64 and we pass it as part of the URL. That’s a great way to get information from one place to another using JSON web tokens.

5. API (OBJ 3.4)

API, the application programming interface. In this lesson, we’re going to dig into APIs. Now, I’ve mentioned them a couple of times, but we’ve never really defined them and gone into depth with them when we talk about an API, this is an application programming interface. It’s a library of programming utilities that are used to enable software developers to access functions of another application. And this is one of the key things we use when we start talking about piecing things together by using things that are service oriented in their architecture. Now, when we deal with an API, this is going to allow for the automated administration, management and monitoring of cloud services, as well as lots of other applications.

Now, these APIs are commonly going to use either Rest, which is the representational state transfer that we talked about before, or Soap, the simple object access protocol, as their frameworks. Now, when we talk about APIs, we think about these from the perspective of integration. APIs allow for integration between lots of different cloud services. Cloud service providers also allow for us to do provisioning, configuration, deprovisioning, and lots of other things to their services through these APIs. So APIs will allow us to have direct integration of different third party applications into our own web applications as well. And again, this is those things that allow us to tie things together and make function calls. Instead of having to build services ourself, we could just call on somebody else’s function and let them do the work for us.

That’s the idea of a service oriented architecture. Let me give you a great example of how we use APIs in our business. Now, in our business, we have a centralized service management system called Freshdesk. Freshdesk is a commercial product that we pay for, and we use this to be able to get all of our trouble tickets from our students and any questions you may have and track those things and make sure you’re getting the answers you want. Now, if you email support@deontrain. com, it goes into our Fresh Desk system, and my team and I can look at those and answer your questions. Think about it like a shared inbox. But again, it’s a ticketing system so we could don’t lose track of it, and we can make sure everybody’s doing what they’re supposed to.

Now, we’ve had students ask questions as well in our Udemy courses, and they do it inside the Q and A section on that platform. Well, I don’t own Udemy, and I don’t have the ability to do what I want and program their system how I want. But they do have an API. So instead of me having to log into Udemy to answer those questions, we instead have an application we built that uses Udemy’s API. Whenever there’s a question that’s posted inside the Q and A section on Udemy, we actually get notified from their API to our Fresh Desk API, and we create a new ticket in our service management tool and tag those as a Udemy Q and A question that all goes from API to API and sends that data back. This is the type of integrations you can do. Now, all of this is being done with a very small program that we wrote.

That integration program is less than 50 lines of code inside a python. And we’re actually connecting these two different cloud systems, udemy and Freshdesk, to be able to accomplish everything we want with just 50 lines of code. Now, when either myself or one of my team members answers those questions inside a fresh desk and we close that ticket, it then triggers a function in the Udemy API to take our response and post it back as a reply to your question in the Udemy Q and A. For you, it’s going to look just as if I went in there and answered it directly on Udemy. But for us, it’s easier to manage and allows us to help more students quicker. In addition to that, there’s a function there that will mark that answer as the top answer, because we wrote it and we want it to be the top answer that you see when you ask a question inside of Udemy.

Now, all of that is how you can use some of these things to integrate. Another example of using an API to access an online cloud service is how we integrate our hands on cloud based labs into our products inside of our own website. Now, we integrate these labs from our partners using their API. We create all the videos, we create all of the lessons, we create all the study guides and all the quizzes. But when it comes to the labs, we don’t build that ourselves. We have a third party partner that we work with, and we want to integrate theirs into our course experience. And we want it to be native for you, so it feels like it’s much more integrated. So if you’re taking this course at Deon train. com, for instance, you have access to that full lab environment.

Now, what happens is, as you’re going through the course, you’ll watch a video and eventually you get to one that says, now there’s a lab. And in this lab, you’re going to do X, Y, and Z. Click this link to start the lab, and that link actually looks something like what you see here on the screen. It’ll say deontrain. com question mark action equals run instance and ID equals and the count and the access key and all those things. These are the parameters that we’re passing to the API of our cloud service provider. So when we go to the lab partner, they’re knowing who the student is, where they are in the course, what lab to run, and which one to start up. And all of that is stuff we send over through an API call from our system to their system, and then it gives you a link, you click on it and it loads up.

Now notice here you have an authorization token as well. This is because the cloud provider needs to be able to know who they’re servicing, because we have hundreds of thousands of students. And by knowing which student you are, they know which lesson you’re on and they can know which lab you need to have, and so they can give you the right services that you paid for and the ones that you’re ready to use. Now, when you’re doing APIs, there are lots of different tools you can use to do this. One of the ways you can test APIs is by using a tool known as Curl. Curl. This is a tool to transfer data from one server to another. And you can do this using any supported protocol, including http https FTP FTPs, SCP, SFTP, TFTP, DICT, telnet, LDAP, or file. All of these are valid ways of doing it.

So if I wanted to test an API as a cybersecurity analyst, I could test it by using Curl. And I might do something like this curl data. And then the data I want to send in this case, I’m sending first name equals boolean and last name equals world. And then where I’m sending it in this case, https http bin post when I send that information, what do I get back? This list, as you see here on the screen, which is a list list of arguments and fields that came back from that particular API. This allows you to send the data over and see what comes back. So if you were hired to do testing of our server and make sure the right student is getting sent to the right lab, you would have to know how to do this to make sure the API calls are being programmed correctly by our developer and that we’re getting the responses we expect.