Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m

Next lesson playing in 5 seconds


Free Preview: Service-Oriented Architecture for Authentication in Ruby


  • Overview
  • Transcript

This course demonstrates an approach to a service-oriented architecture. We will use Ruby to create a authentication system that’s based on the Central Authentication Service (CAS) protocol: a single-sign-on / sign-off protocol for the web. Through the use of object oriented design, you will be able to create a Sinatra application that implements the aforementioned protocol specification, along with a demonstration client application that will consume those services.

Related Links

1. Introduction

1.1 Introduction

Welcome to tuts plus. My name Jose Mota. And this course will build a central authentication service with the Ruby language. So, what is this really? You might be wondering, what specific use cases we'll be covering. Well, let me show you. Here is a simple diagram to demonstrate the power of using such a service. I wanted to show you this to demonstrate how you can flexibly use a single user base for many different applications. You can have your business logic on one app and then you want to integrate other services along with them. For example, reporting applications, a chat app, for example, with your users' payments and for example, a shopping cart. This way, you get a service oriented approach to managing users. We're going to build a small subset of a protocol specification. By the JASIG group. They have a central authentication system of their own, but it's built in Java. So we're going to build one in Ruby. We're going to cover part of the specification, because even though it is small it is rather complex. I remember back in the time when I was learning about this. It was very hard to understand all of the bits and pieces of the protocol specification. We're going to cover a part of it. Don't worry, as the source code will be provided in order to assist you in your learning process. Just to let you know, this is kind of an advanced course. The code base that we'll study today involves a lot of knowledge on Ruby and object oriented practices. So, if you're still a bit uncomfortable about these, don't worry, it's okay. Just go back to the other courses in the network and you'll do just fine. Do those first, and then jump back in. I'm sure you'll feel a lot more comfortable. So, I hope you're excited about this. Let's get started. Let's jump right in to the next lesson.

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.