7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
FREELessons: 17Length: 2.7 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

1.2 Getting to Know the Protocol Specification

Before jumping straight into the code, I want to show you something around the specification of the protocol we'll follow. This is the GitHub depository for the Jasig group, namely the Essential Authentication System that is implemented in Java. We're not going to be able to use this at all. But still, the documentation, which you can see by this folder, contains the protocol specification. If you scroll through the documentation folder, you will have this file inside the protocol folder. It is the 3.0 Specification. I'm not going to read this line by line to you, I think you should do that on your own. But still, I want to demonstrate the basic workflow that it's also a fallible in this protocol folder. You will see this image inside the protocol file. I'm going to skim this group really quickly for you so you can get a quick glance of what we'll do. So, let's get started. You can see that we have a user that's represented by the browser. The user wants to go to a particular app, so, it uses the browser to accomplish it. So, let's think of these two as a single one. The browser will try to reach out to an application that you see on the far right side of the screen. The app is protected against regular users that are not signed in, so it prevents anything from happening. Instead, it is going to forward the request back to our central authentication server, which in this example is represented by this URL, and notice how we're going to go to the login method. The next things should be to pass in a service. The service parameter matches our application URL. After that, we're going to try and log in, but we don't have any session present, and because of that, we're going to have a log in form to fill basic stuff, just fill in, for example, the email and the password. After we do that, the POST request will be sent with that data. We will have the user authentication procedure happening, and as long as we do it okay, we will have a cookie being printed out to the request. A new cookie will be established in our session, and so we will be redirected back to our application. You can see app.example.com again. But this time, we will have a ticket parameter. It is a surface ticket that will represent this particular service back in the authentication server. So, we're gonna go to that example.com site, it's our basic application. And then, we'll need to validate that service. This is just to make sure that our service is valid in the context of the authentication server. You might want to limit the set of applications that are linked to the authentication server. So this step is necessary. So we're going to validate the service and we'll retrieve an XML document, which contains information on our user. Based on that, we'll have the session cookie established with all of the data that we need in order to set the session, such as, for example, the name, the email address, so we can have, for example, a navigation bar with our name and email address in there. So after the session is correctly established, we'll be forwarded back to the application without the ticket, because we don't need it since we already have the session in place. With that, we can go straight to our application, the session exists, and the content will be retrieved. Fairly straightforward, at least from this part forward. Now, the good parts come after this regular workflow. The second access to the same application is just as simple as validating the session cookie as you would normally. Even better is to access a second application to our user data. Because the second application doesn't have any session data, we're going to be redirected to the login method in the authentication server app. However, because we have that cookie set, it is going to validate it, and then, it is going to emit a new service ticket for that specific second application. We're going to validate it the same was as we did in the first app. Retrieve the XML document, create a new session, and retrieve the content. This is the basic workflow that we should prospect. I told you before that we're just going to follow a small subset of the specification. For example, we're not going to cover proxies or anything like that. And also, we're not going to validate the service tickets right away, you know, validate against a whitelist of services allowed, something like that. So, I encourage you, once again, to read the specification. Most likely you will feel very, very confused. As I've mentioned, this is a hard protocol to follow, but it is a good read, nonetheless. Some details about the process illustrated in the workflow will be revealed, and they will be very interesting to know about when we jump into the next lessons and implement this protocol. So, jump right away to the next lesson where we'll start considering some aspects of the spec.

Back to the top