Integrated Single Sign-on with CAS protocol

I believe you are not unfamiliar with the term "single sign-on" (Sso,single sign on)? Simply put, single sign-on allows multiple applications to use the same login service. Once a user logs on to an application that supports single sign-on, it is no longer necessary to re-login to other applications that use the same single-point login service. And the CAS protocol is the single-point landing products need to implement the Protocol, which is all called Central authentication Service.

Then why do you write this blog? This is because when it comes to integrating SSO for the company's products, I find that if the software developer does not understand the CAS protocol, then he will have absolutely no way to analyze the cause of the error when the integration is wrong.

Introduction to Single-point landing

If you do not know what a single point of landing is, then first to experience a single point of landing. First, type www.hotmail.com in the address bar of a new browser (or a browser that clears the login cache) and go to your Hotmail mailbox. Next, we'll visit www.msn.com. Please look at the top right corner of the webpage and you will find that you have successfully logged into the www.msn.com via your just Hotmail mailbox:

This is single sign-on: Even if Hotmail and MSN's domain name indicate that they are completely two different websites, but because they use the same single sign-on service, so after landing Hotmail and then landing MSN, the user credentials you just entered are still valid.

This ability to directly access other applications in one place is very useful in enterprise applications. Imagine a scenario in which we always have to access dozens of systems through a browser in our daily work. If you are viewing corporate mail in a browser, you need to log in to your company's wiki system when you need to write a wiki. And the reimbursement, leave, the company shared file server and so on need user login. And if a company's IT department is more concerned about security, they will also ask employees to change the password within a certain amount of time. Imagine that if there are dozens of systems inside the company, then each employee needs to maintain dozens of passwords, and every few days it needs to change a password for one system. The cost of this kind of password management is enormous both for the employee itself and for it overhead.

Conversely, if these systems use the same user login service, then we can dispense with the cost of entering a password every time a system is logged in, and each employee only needs to manage one password.

Therefore, if you want your enterprise applications to successfully enter a large enterprise, then this product must support the standard single sign-on protocol, the CAS protocol. Only by correctly understanding the CAS protocol can we correctly add support for single sign-on in our products. And that's the real reason I wrote this article.

CAS Workflow of the Agreement

Now we know the benefits of single sign-on, but we don't know how it works. Since the implementation process of the CAS protocol is complex, let's first look at a life-like example of single sign-on to help us understand the single sign-on run process.

Assuming the company is about to come to a new colleague, the company's executives need to furnish him with all kinds of office supplies needed for his daily work before the colleague arrives. These office supplies include a working computer and a new set of desk chairs. After the purchase of these office supplies, the administrative staff to buy office supplies when the invoice issued to the company's financial department reimbursement. To save time, the executive will use the company's vehicles to transport goods between the company and the store.

Because the company's drivers often travel outside, so he may not know that the day need to carry the administrative staff to buy office supplies. After the administration found him, he was unable to confirm whether the administrative staff's vehicle arrangement was in conflict with the company's other arrangements. So the driver will let the executive call the company's leader to make sure he can use the car. When the leader received the call from the executive and stated the reason for the use of the car, the administrator would forward the call to the driver and let the driver communicate with the leader. After receiving a positive reply from the leader, the driver can safely carry the administrative staff to the computer city to buy a computer.

When the administrator found the driver again on the same day and said he needed to buy office chairs, the driver no longer needed to call the leader. Because he has already called and the leader has inquired whether the administrative personnel need to use the car thing.

After all the office supplies have been purchased, the administrative staff will go to the company's financial department for reimbursement. After meeting the financial personnel, the administrative staff will be directly said and led before the ditch passed and received approval. After the financial officer calls the leader and simply mentions the purchase of office supplies, the leader quickly confirms the need to buy office supplies for a new employee. Upon receiving a positive response, the financial officer will accept the claim directly and proceed quickly to the clearing process.

Throughout the process, administrators are both visitors and users of resources. Each time you try to use these resources, the manager of the resource needs the leadership's approval to give the administrator the right to use the resources. Just at different times, the amount of information that leaders and resource managers get is not the same, resulting in three different processes for using resources.

In the first use of the car, because the driver and the leadership is not clear that the same day the administrator needs to use the car, so the administrator needs to get a permit from the leader to use the car, and the leader's permission to transfer to the driver, and thus the right to use the company's vehicles. In this process, the administrative staff need to communicate with the driver, but also need to communicate with the leader, and the driver needs to communicate with the leader.

In the second use of the car, because the driver has been aware of the leadership of the vehicle use authorization, so he no longer need additional communication and directly allow the executive to use the company's vehicles. In this process, the executive only needs to communicate with the driver, and no longer need to greet the leader.

In the process of reimbursement, because the financial personnel do not know whether the purchase of office supplies have been approved by the leadership, so need to ask the leader. At this point, the leader already knew that the Treasurer was the office supplies for the newly-appointed colleague, so he would directly agree to reimburse the money and no longer need the executive to explain to the leader the company's future new employee. In the process, financial personnel need to communicate with executives and leaders.

The process of running the CAS protocol is essentially the same as the example above: when you first access an app, the user will be asked to go to the SSO system, enter the user name and password that represents their credentials, to get access to the app. In the second visit to the same application, the user is directly allowed access to the app because the app already knows that the user has been granted access. If a user accesses another app, the app will authenticate to the SSO system based on the credentials that the user is currently getting, knowing that the user already has access to the app.

Here is the flowchart for the first time you access the app and log in successfully via the CAS protocol:

The flowchart above lists the steps that users will need to experience the first time they log on to the app. First, the user tries to access the app by typing https://app.ambergarden.com in the address bar of the browser. Because the app session is not created at this time, the app rejects the user's logon request and redirects the user to https://sso.ambergarden.com with a 302 response to require the user to first log on through SSO. Note An additional URL parameter service is included in the address indicated by the redirect. It identifies the location of the app that the user originally wanted to access. After the browser receives a 302 response, it automatically jumps to SSO. Since no corresponding session has been established with the browser in SSO, it will be returned to the user with a login interface that requires the user to complete the login by entering the user name and password. After the user enters the username/password and clicks the login button, the page logic sends a POST request to SSO to establish the session. If the user is logged on successfully, SSO returns a 302 redirect response with an additional parameter ticket for the address indicated by location in the redirect response. After the browser receives the redirect response, it sends a GET request to the redirect address, and the request also contains the ticket parameter that was just returned from SSO. After the app accepts the request, it sends the request to SSO with the credentials indicated by the ticket parameter to verify the legitimacy of the credential. If the validation succeeds, the app will assume that the current access to the app is initiated by a legitimate user who has been authenticated to the SSO, creating a session for that user.

When the browser accesses the app again, the app will be able to identify it as a legitimate SSO authenticated user because the app has created the appropriate session for the current browser:

The flow chart for a second visit is actually very easy to understand compared to the first visit to the app. In fact, this is the flowchart that accesses the app again after the session has been established.

While accessing other applications, the CAS protocol runs a flowchart that looks like this:

If you have understood the first sign-in process, then the process is very easy to understand. First, the user tries to access the app under Https://app2.ambergarden.com. The app sends a 302 request to redirect the user to the SSO service because the app was not signed in by the user before. The URL parameter service here is the same as the first login, which is used to record the service address to be returned to when the login is successful in this series of communications.

Once the browser receives a 302 response, it will immediately perform a redirect and access the SSO service. Because the user has already established an SSO session prior to accessing the first application, the SSO service will immediately return a 302 response and use the URL parameter ticket in the response location to indicate the user's credentials from SSO. After receiving a 302 response, the browser redirects again and accesses the app. The application also uses the credentials indicated by ticket to authenticate to the SSO request. After validation succeeds, the app will assume that the current access user is legitimate, so the session will be created for that user. In this process, the user does not enter any information, but only after a few browser jumps to verify the legality of the user.

CAS Protocol Integration

Well, after understanding how the CAS protocol-based SSO works, we can start to think about how to integrate the support for the CAS protocol in the application.

The first step we have to take is to analyze how each of the various processes described above can be used in each of the interfaces defined by the CAS protocol. In the process of analysis, we need to always remind ourselves that we are adding CAS protocol support for our application, rather than implementing a CAS protocol-based SSO. This results in the following differences in the way we view the CAS protocol with the implementation of a CAS protocol-based SSO:

1. It is not necessary to understand all the interfaces in the CAS protocol and all the parameters in each interface. Many of the interfaces listed in the CAS protocol are actually used to interact between the browser and the SSO service. So we don't have to look at these interfaces very carefully, we just need to know the functions that these interfaces perform and the resulting data. And even the interfaces we use will have some of the parameters that will not be used. We only need to focus on the various parameters that may be involved in our application's use of the SSO process.
2. You need to be aware of the interaction between the browser and the app in the process. As you can see in the various flowcharts shown earlier, the application is done by using HTTP standard methods such as a series of 302 redirect responses to redirect users to the SSO service.

So let's go back and recall the flowchart of the user's first successful landing:

In this flowchart, we need to be concerned about who has interacted with the application and what interfaces and parameters were used in the interaction. As you can see, when the user first accesses the app through the browser, the app needs to return a 302 response to the user, and the address specified in the response is the login interface provided by SSO. So the first step we have to take is to understand the work done by the login URL.

As you can see from the API documentation, the login URL can provide two services: requesting the user to enter credentials (credential requester) and authenticating the user's credentials (credential acceptor). In this flowchart, we send a request to the URL two times. The first request uses the first service of the URL, which requests the user to enter the user's credentials, such as displaying a landing page. When a user enters a user name and password, the second service is used for requests sent to that URL. In these two requests, the service parameter in the URL is used to indicate the address to which the user needs to jump when redirected from SSO after a successful login. Since we are adding SSO support for our app, the service naturally needs to point to our app.

OK, now we can start the first step integration. The work of this step is: When a user accesses the application, if the user does not have a corresponding session, then return 302 response, and in response to indicate the address of the jump is the address of the SSO, and in the service parameters to indicate the address of our app. If all of these functions are implemented correctly, access to the app automatically jumps to the SSO service and requests access to our own app again after a successful login. The access at this point passes in a URL parameter ticket to represent the credentials obtained from SSO.

If the integration of the first step is completed correctly, then we can begin the second step of integration, which is to authenticate the user to the SSO service. In the first step, SSO eventually verifies the identity of the user and returns a 302 response to the browser. When the browser receives the 302 response, it jumps to the address indicated by the 302 response. After the application accepts a request that contains the ticket parameter, it needs to access the Servicevalidate interface using the information logged by the ticket parameter to verify that the incoming ticket parameter is a true credential returned from SSO. Once the validation is successful, the user is a legitimate user. At this point the app needs to create a session for the user and redirect him to the program's initial page, such as the app's dashboard.

When the user accesses the app again, because the user's session is already included in the app, it no longer interacts with SSO and therefore does not need to do any work for SSO integration. Again, because the third process uses the same interface, we no longer need to do any extra work.

In this way, with just two steps, we can complete the integration of SSO login functionality. Isn't it simple?

In addition, we can also choose to support single Logout (some discussions are called Single Sign Off). But there are a lot of people who oppose this function. The reason for this is that users often think that clicking the logout button exits safely from the current app, but this actually causes all apps that use the SSO service to log out. Therefore, before deciding to support this feature, it is important to consider whether the feature will actually benefit the user.

Issues to be aware of

As you can see above, integrating support for SSO in your app does not actually require much work. It can even be said that a person with relevant experience can be completed within a few hours. But conversely, if you don't notice some of the problems in the integration, these issues can delay you for a few days. So in this section, I'll simply mention some of my experience in SSO integration.

The first is the CAS protocol API document reading method. I've always thought that for this process-oriented protocol, the process of running the protocol and the flow of data in the process are critical. So it's not a good idea to go into the API documentation and try to understand the meaning of each interface, input and output. Perhaps for foreigners, understanding the interface to understand the operating process is a relatively simple way, but it seems that this way is not very suitable for Chinese thinking. That's why I've been explaining the running process for SSO on the first step.

In the CAS protocol API documentation, there are several sets of interfaces for validating ticket, such as the/validate interface in the first edition evolves to/servicevalidate and/proxyvalidate two interfaces in the second edition. Please select the appropriate set of interfaces as needed.

One thing to keep in mind is that many SSO have a filter that identifies the various applications that allow the SSO service to be used. This filter prevents illegal apps from logging on from the SSO service. Otherwise, the illegal app will be able to attempt an attack on SSO. Cite one of the simplest examples of DDoS attacks. In one of my blogs, the validation of username/password pairs is actually a time-consuming behavior, so this step is the most vulnerable part of the SSO service. If a malicious person stares at the SSO service and finds a vulnerability on a Web site with a large base of users and changes its SSO service configuration, users of that site will be redirected to the SSO service when they log on to the site. These users will then attempt to log on to the SSO service with their username/password, thereby launching a DDoS attack with the help of these users. As a result, the SSO service will typically configure a whitelist. And before we do SSO integration, we need to add our app to the whitelist first.

Another problem that is more easily overlooked is the timeliness of the session. There are two sessions throughout the use of SSO: the user's session in the application and the user's session on the SSO service. In general, the session duration on the SSO service is slightly longer than the session time in the application. This allows the user to re-establish the session from the SSO service directly, such as by refreshing the page, when the application's session expires. However, in the case of integration, for ease of debugging, we often adjust the application session time long, even longer than the session time on the SSO service, thus not testing the application session expiration and then refreshing the application session through an SSO session.

Reference

CAS protocol: http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html

Reprint please specify the original address and marked reprint: http://www.cnblogs.com/loveis715/p/4491417.html

Commercial reprint please contact me in advance:[email protected]

Integrated Single Sign-on with CAS protocol