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

1. SOA and Microservices (OBJ 2.2)

SOA and microservices. In this lesson we’re going to start talking about the way systems are designed these days by using serviceoriented architecture and microservices. Now, in the old days, the legacy way of doing things, we would build these huge monolithic networks and we’d have to get our routing and our security and our servers. We put all this stuff together to build these huge networks to perform one function. Everything was very tight, they coupled and so when something went wrong we had to identify exactly what it was. Well, these days it becomes a lot easier for us to build things because we’re using a lot more of this service oriented architecture. When we talk about service oriented architecture, this is a combination of lots of different little pieces like the system, the service, the platform, the practice, the people, the architecture, the process and the integration.

And each of these can be operated individually so they’re not tightly coupled anymore. Instead, we call this a loose coupling. Now, when I talk about service oriented architecture or SOA, this is a software architecture where the components of the solution are conceived as loosely coupled services, not dependent on a single platform type or technology. By doing this, each individual piece can be built on its own and tested on its own and that way there’s no dependencies existing between these. It makes it a lot easier for us to build applications and reuse components. Now, each service is going to take defined inputs and produce defined outputs. Essentially we call this like a black box type of architecture. I’m going to say this thing does this function and it takes these things as inputs and it’s going to give you that thing as the output.

So if I have this box, it’s going to do some math problem. You’re going to give it two inputs and it’s going to add those things together and give you an output. That would be an example of a very basic service oriented architecture example. Now when we start dealing with service oriented architecture we use this idea of decoupling. We decouple these services into these different layers. Now everything is connected together by providing a specific type of input and they’re going to provide you with a particular structure for that output that you’re expecting. Everything in between is really a black box. We don’t really care what happens as long as we get what we want. This allows us to essentially have a bunch of building blocks that we can use at these different layers and to do these different functions.

For example, we have a presentation layer at the top or we have a business process layer. Underneath that we have service component layers, we have messaging layers that have a connection to legacy systems all the way down to the underlying enterprise information technology systems. And each of these can be designed, built and tested individually in a decoupled manner. When we look at these services, they’re going to be defined within the scope of functional business requirements and these things can then be reused for different purposes. As you look at these different services, you’re going to look at them and go, this service is going to be used for this function. This is a SMS program. It’s going to take some message and send it out as a text. This program might be something that’s going to get things in through email and then it’s going to output it in this other format.

Whatever it is, you’re actually going to build it’s all based on your functional business requirements and allows you to reuse them time and time again. Now, one of the things we have to consider is that if we have all of these services that are being built in a decoupled manner, how do we get them to communicate together? Well, we’re going to use something known as the Enterprise Service Bus or ESB. This is a common component of SOA architectures that helps us facilitate this decoupled service to service communication. When you look at service oriented architecture, it is going to be looked at from an overall design architecture and it’s a way for us to map the business workflows to the It systems to support them. Again, our whole function here is to figure out what is the process we’re going to do, what is the business process that we need to mimic.

And based on that business process and workflow, we can then pull all these different pieces and services together with those It systems that will support those services. Now, one of the things that really helps us with this is the idea of microservices. Microservices are software architectures where the components of the solution are conceived as a highly decoupled service, not dependent on a single platform type or technology. Again, by using these microservices and designing our systems in this way, we are actually having a paradigm shift. We’re thinking about doing things differently in terms of application development. When you’re using a microservice architecture, it’s going to have some of the same general principles as SOA.It sounds a lot of light, doesn’t it? Now when we look at these, they’re going to contain things like self contained service modules, each one performing a single function with clearly defined inputs and outputs.

Sounds a lot like SOA, right? We’re also going to then take those services and apply them to the design of network applications such as an order processing system, a video streaming service, a messaging system, an email system, a file support system. Whatever those things are, we can take them, network them together and create a larger service. So you may be asking yourself what’s really the difference between SOA and microservices because they sound very, very similar. Well, when you see SOA, I want you to remember that so it allows applications to be built from services with some interdependencies. Now, when you start dealing with microservices, on the other hand, you’re going to have microservices that are capable of being developed, tested and deployed independently.

These microservices are more easily scalable than a big monolithic app because only the necessary service modules you need will need to be scaled up to support it, rather than having to provision additional resources for the entire application infrastructure. So when it comes down to what is the difference between SOA and microservices, remember, if we take services and we put them all together in some kind of a business process and we create interdependencies, that is SOA, that is a service oriented architecture where everything that runs that is a service. And we connect them all together. When we start dealing with microservices, they’re independent. They are one individual thing that’s going to be developed, tested and deployed. And so really, it’s all about interdependency. When you’re dealing with SOA, you have those connections. When you’re dealing with microservices, you don’t.

2. SOAP (OBJ 2.2)

Soap or simple object access protocol. In this lesson, we’re going to talk about Soap and not the kind that you wash your hands with. Instead, we’re going to talk about the thing that allows serviceoriented architectures to provide services with access from different sources. Now, when you take all these different services and you try to put them all together and have that loose coupling so that they can actually operate and pass things back and forth, they need a way to communicate. Now, this is really important because when people are building all of these loosely coupled services, they can write them in all sorts of different languages. You might write yours in Java, I might write mine in Python. Somebody else might use JavaScript, somebody else might use Perl or Ruby. And if we want them all to talk to each other, we need a common way to do that.

Well, that is what Soap is really about. Soap is the Simple Object Access Protocol and it provides an XML based web service protocol that’s used to exchange these messages. Soap is going to provide a structure for transmitting and receiving information that’s used in these web applications to a variety of device types using an application programming interface known as an API. Now, when we use Soap, it’s going to help us to support the authentication, the transport security, the Asynchronous messaging, and built in error handling. So it gives us a lot of good benefits. Now, when you start using Soap, you need to make sure that you’re thinking about it from a security perspective too. One of the biggest things is to always use it using the least privilege.

This way when these services are communicating to each other using Soap, they’re doing that with the least privilege and it prevents you from having privileged escalation and reduces the chance that people get into things they shouldn’t. Additionally, you want to make sure your security framework is using a deny by default policy and you want to provide the needed levels of access to data and other network resources that are needed by these services, but you want to do it in a secure mechanism. Now, when we start talking about Soap, we want to make sure that we leverage Web Service Security or WS security. These are extensions that are used to enforce integrity and confidentiality when you’re communicating over Soap. Now, Web services using Soap may be vulnerable to several different types of exploits.

And that’s what I want to focus on in the rest of our time together in this lesson. These include things like probing, coercive, parsing, external references, malware, and SQL injection. And so we have to be aware of these different exploits so that we can then figure out how we can help prevent them. For example, if you’re dealing with probing, this is a preliminary attack that’s used to conduct reconnaissance or enumeration against the Web service. So if somebody using Soap and it’s a way to communicate between services. That means somebody could also use Soap to try to do reconnaissance or enumeration against your Web service. They might send things against your API and see what the response is. And by doing that, they can start fingerprinting it and footprinting it and figuring out how it works.

Now the second thing we have to be aware of is coercive parsing. Now this is an attack that modifies requests to Soap Web Services in order to cause the service to parse the XML based request in a harmful way. Remember, we said Soap is used to communicate things between these different Web Services and the format they use is XML based. So if I can get you to parse the XML file and do things in a harmful way, I might be able to have a payload that’s crafted inside of XML and when you read it and parse it, that’s going to take that payload and then trigger it on your system. That might cause some kind of an exploit to run or even a denial of service, in which case I can then take down your servers.

Now the third thing we have to think about is when you’re dealing with these Soap services, if you poorly configure them, they can actually make exploits available. And a lot of times because you’re dealing with XML, a lot of these things have external references. Now, when you’re dealing with external references, this is where you’re calling something like a third party library in or you’re calling some third party file on some other site. This is kind of like a remote file inclusion. And if you do this, it’s going to allow this external reference to take over and bring that exploit into your server. Another thing we have to be worried about is malware, because malware can be inserted into these XML messages and they could be used to compromise the service.

So you want to keep that in mind as well and make sure that you’re doing good input validation and good checks of these XML messages before you parse them. The final thing is we want to make sure we’re avoiding SQL statements being sent over Soap, especially when we’re trying to do things like a deletion, a modification, or access of an SQL database directly. If we can do this, this can help us avoid SQL injections. Because again, Soap by itself doesn’t have the ability to filter these SQL statements. And so we want to make sure that as a best practice, we’re not allowing SQL queries going directly over the Web through the Soap protocol into our SQL database. Instead, we should receive those, we should process those, and then if they’re safe, push them into the database.

3. SAML (OBJ 2.2)

SAML the security assertions markup language. Now, SAML is another XML based data format and this one is one that’s used to exchange authentication information between a client and a service. This is used to send things like our authentication for the user, the entitlement to the user and the attributes of the user. And often we’re going to pair this up with Soap so we can use SAML and then send it over to the Soap protocol call. Because Soap is used for authorization, not authentication. And so by pairing these two together, we will get authorization and authentication. Now, when we’re dealing with SAML, this is often used to provide single sign on service or SSO or a Federated identity management system. This allows the service provider to establish a trust relationship with the identity provider.

This way the identity of the user, which we call the principal, can be trusted by the service provider without the user ever having to authenticate directly with the service provider. Now, I’ll explain how this works as we go through this lesson. Now when you look at SAML, its header looks something like this. Essentially you have Sam’l information that’s being communicated in the form of assertions. And this is why we call it the Security Assertions markup Language, or SAML. As I said, these assertions are used for authentication and they’re going to contain information about the user’s identity, making sure it’s valid, making sure you have information about the user, and information about the level of access for each user. You take this Sam’l request a response, you wrap that as part of the Soap body.

Then you use the Soap header to get it where it needs to go. All of that is wrapped inside the Http body and then you have the header on top telling it where it needs to go. Now, as we look at this, I want you to think about it like this. We have three roles here. We have the service provider, the user agent, which is usually your web browser, and then the identity provider. Let’s pretend that I’m the service provider and you want to log into my website, but I don’t do my own identities. Instead, I’m going to allow you to sign on using, say, your Google Log on. That would be the identity provider. So the first step is you as the user, go to my website and you request the target resource. So you go to Deontraining. com and you click on Login.

When that happens, you and I are going to do this little handshake where we discover the identity provider. We’re going to say, hey, I support Google Log on, do you want to use Google Log on? And you would say, sure. Well, when you click that Login button, I’m going to then redirect you to the SSO service, the single sign on service that goes back to your browser. And your browser then makes a request to Google Service, the identity provider. They are going to do the identification with you, making sure your username and password is right. Then they’ll take all that information they know about you and respond within an XHTML form that goes back to your browser. Your browser then takes that and then does a request assertion for consumer service.

Essentially you’re going to send the information you got from the identity provider, which tells me this person has been authorized and these are the permissions they should have. Then that goes over to me. Once I get that as a service provider, I say this is John. John is allowed to access my videos. Let me log in and give John access to those videos. So I then send the videos back to you. At that point, if you want more things, you can request it again because you’re already authorized. You can say, okay, I’ve finished watching this video, show me the next one and then I would respond back with that requested resource. Okay, here’s video number two and then video number three and video number four. And that’s how this works.

So steps one through five is essentially where we’re doing this SAML thing and Soap thing where we’re getting that information and sending those assertions over using SAML. Then once you have that in six, seven and eight, we’re just going to keep going back and forth with that authenticated session, giving you the services you asked for. Now if you want to see what a sample request string looks like, it looks something like this. For instance, here I have IDP deontrain comloginmark SAML request equals and then this encoded string. Now notice this was IDP deontrain. com. Here I’m pretending I am the IDP provider so I would be Google single sign on service. For instance. Now when you do this, it can be sent from the user to the identity provider as an Http 302 redirect, which is what I’m showing here.

And this is done with the XML request. That part in blue being encoded as a string as part of the URL, that information that Dzbba, that part is part of this encoded string. And we can actually take that and send that into the identity provider through this form and then they can go and get the assertions for you. Now what does this look like when you start blowing it up and looking at it? Well, here is a decoded Sam’l request string and it contains a lot of information in fields as you can see here on the screen. Now this is simplified for our explanation and the real SAML request string could have a lot of additional fields. The field grouping of data contains things like the protocol that’s going to be used, the identification to identify the user, and a date timestamp when the request was made so we can know if it was expired or valid.

You can also see the capability exists to include a digital signature notated by the grouping as DS signature in the request towards the bottom. This will be used for non repudiation to validate the origin and integrity of the Sam’l request. Once the request is sent, the reply is going to come back as an assertion. Now, the assertion is going to look something like this. And it may be a little bit harder to read because there’s so much data here, but even here I’ve simplified it down for our use. This is a response and you can see here in the second line that it has an ID value, in this case 200, as well as a date and timestamp to prevent an expired one from being used. Notice at the end of the third line, it says it’s in response to and then an ID number. If you noticed in our request, it identified itself as Request 100.

Now we’re replying back as an assertion for Request 100. Now, towards the lower half of this assertion, you’ll start seeing where we have the subject, the conditions, the restrictions and the attributes associated with that user that the reply is being sent on behalf of. These are the assertions that are being made. These are all the different things that we know about this user. And we as the identity provider, can tell the service provider what they should know about this particular user. Now, the signature here is going to be verified and a session is going to be established once that response is received by the service provider. So as a service provider, I get those assertions. I look at it, I verify that digital signature and I say, yes, that looks good to me.

Now I’m going to create a session with the end user and start fulfilling those requests. Now, for the exam, it is unlikely that you’re going to get questions that dive deep into SAML and how it works. But in the real world, this is a concept you should be familiar with. Now, many web services rely on identity providers as part of a federated identity management program and that all relies on Soap and SAML. By understanding how it works, you can better understand if an attacker is trying to exploit the trust relationships between that service provider and the identity provider by spoofing or modifying these sample requests and those response messages and assertions that come back from them.