SSO and CAS knowledge required for the front-end
Camellia in full bloom
Cloud community system software programming language front-end and interaction design javascript CSS HTML5 server domain name user experience browser cookie
Abstract: No matter what company, as long as the number of products is larger than one, then single sign-on is bound to be a problem. As front-end programmers, we don’t know much about it, but we need to understand it properly. This article will talk about single sign-on related issues. Prior knowledge to UNDERSTAND SSO, the following knowledge is desirable.
For any company with more than one product, single sign-on is a problem. As front-end programmers, we don’t know much about it, but we need to understand it properly. This article will talk about single sign-on related issues. Prior knowledge to UNDERSTAND SSO, the following knowledge is desirable. Of course, if not particularly familiar, also does not affect reading.
Cookie and Session Browser Same-origin policy and Cross-domain Understanding what constitutes the Login System What are SSO and CAS?
SSO
SSO is short for Single Sign On, which translates as Single sign-on. As the name implies, it extracts the logics of user login from two or more products to achieve the effect of logging in to multiple products at the same time only by entering the user name and password once. The advantages of using SSO are clear: improved user experience. Take my factory as an example. My factory has two products, lilac talented person net and lilac garden forum, if you are my factory user, affirmation cannot bear to enter user name password when logging in lilac garden forum, login talented person net should input user name password again? Avoid repetitive development. If you are my factory back-end, daily tasks are saturated not, certainly can’t bear to talent network development of a logon logic, to the forum and development of a logon logic? Improve the safety factor If you are the operation and maintenance of our factory, found a hidden safety problem needs urgent repair. Surely you can’t stand the idea of sending an email to the back end of so many products ordering them to be fixed? What if you miss one?
If you want to learn about the front end, you can go to the Q group, which is 291 first, 851 in the middle, and 189 last, where you can learn and communicate, and you can download materials. CAS SSO is simply an architecture, a design, and CAS is a means to achieve SSO. Both are abstract and concrete. Of course, there are other ways to implement SSO besides CAS, such as simple cookies. The Central Authentication Service (CAS) is an open source protocol, with versions 1.0 and 2.0. 1.0, called base mode, and 2.0, called proxy mode, are suitable for single sign-on between non-Web applications. Co-domain SSO is the simplest case, as shown in the figure. At this point, both products are under the same domain name, so single sign-on is a natural choice. Let’s go through the steps. Make sure that these steps are the basis for understanding the rest of the text. Don’t skip them. The user accesses product A and sends a login request to the background server. After the login authentication succeeds, the server writes the user login information into the session. The server generates a cookie for the user and adds it to the Response header, which is written to the browser as the request is returned. The cookie’s field is set to ddxy.cn. Next time, when a user accesses product B with the same domain name, the browser will automatically bring the previous cookie because A and B are under the same domain name, which is also ddxy. cn. At this point, the background server can verify the login status through the cookie. In fact, this scenario is the simplest and most traditional login operation. Although we artificially separate products A and B, since they are in the same domain, it is ok to consider them as different categories of the same product. We did not set up a separate SSO server because the business backend server itself was sufficient to assume SSO functions. SSO In the same domain is a simple upgrade of SSO in the same domain. The only difference is that when the server returns a cookie, the domain of the cookie is set to the parent domain. For example, if the IP addresses of two products are respectively A.dexy.cn and b.dexy.cn, the cookie domain should be dexy.cn. This cookie can be sent to the server when accessing both A and B, essentially the same as same-domain SSO. Cross-domain SSO As you can see, in both cases, we did not set up an SSO server specifically. However, cookies cannot be shared when the two products are in different domains, so we must set up separate SSO servers. At this point, we implement SSO through a standard CAS scheme. Rounding out the CAS
The CAS 1.0 protocol defines a set of terms, a set of tickets, and a set of interfaces. Terms:
Client: indicates a user. Server: The central Server that is also responsible for single sign-on in SSO. Service: Services that require single sign-on, equivalent to product A/B above. /login: login interface for logging in to the central server. /logout: logout interface used to logout from the central server. /validate: verifies whether the user has logged in to the central server. /serviceValidate: Used to allow individual services to verify that a user is logged into the central server.
Use the cloud habitat community APP, comfortable ~
For details, please click
Review articles (0)