More than 10 years of single sign-on work experience, and the choice of single sign-on solutions, pure saliva

I have been in contact with single sign-on for more than 10 years. I have been in
contact with single sign-on for more than 10 years. From writing code to develop a single sign-on system, to gradually using open source CAS as a solution, I can be regarded as an old driver in the industry.

Self-developed single sign-on
I have developed two sets of single sign-on systems;
the first one was developed using petstore+EJB, which is used for the parent company's group marketing integration project. There are only three connected systems, all of which are marketing system. It has been running for two years, just in time for the integration of the company's group-wide Internet projects. Considering that this single-point system has poor support for clusters and cannot meet the number of users in the future, I still wrote a second set of single-sign-on solutions, internally named CAS2. (But this cas is not yale cas)
In 2007, it was developed using the popular Struts1+Spring+Hibenate2 at the time. I developed it by myself for 3 months, and the test went online to replace the original PetStrore version. This version has been running so far, more than 10 years have passed, and the system is still running stably. A few years ago, I left this company. At that time, there were about 30-40 connected systems, and more than 100 wars were connected, with an average of about 20 requests per second and more than 300,000 requests a day. 2 blades and 4 services are used as a cluster, and the performance is still very good; due to the completely self-developed project, the system has strong scalability, but unfortunately this architecture is too old now, not many people know Struts1, and we have to modify this source code It is still very difficult, and there are still too many systems connected. Except me, no one dares to modify the code casually.
It is said that the company is launching a new SSO project internally, and it is time to replace this plan.
At that time, in addition to SSO, I also developed a unified user rights management system and system framework around, and realized a unified login scheme. Things that seem to be very low now are still at the forefront 10 years ago, and I also submitted a patent for the overall solution.

Contact Yale CAS
left for a new company, which is the headquarters of the group, and I was responsible for the SSO upgrade of the entire group.
There were 3 options at that time.
Option 1, of course, you can choose commercial products
. Option 2. Develop a new SSO system yourself
. Option 3. Choose open source SSO products.
I always think that option 1) commercial products have too much uncertainty. , and some of the needs of large conglomerates are unique and not standard features. Many commercial companies are reluctant to add non-standard functions to their standard products, which is not profitable for them, and the operation and maintenance costs are too high in the future.
Option 2) Self-built SSO is of course good, but I am currently in the IT department of the group, and there are no code developers, so it is not suitable for self-development.
Therefore, scheme 3) was adopted in the end. For open source SSO products, secondary development is selected, which is low in cost and fast and stable in implementation; if you do not have the time, you can also find a commercial company for secondary development, and the cost is also Low, other companies are also willing to take orders.
In this way, the finalized plan is an open source product, and the secondary development is done by yourself.
Using open source products, it is the commonly used Yale CAS in the industry. Because many companies use it, many domestic manufacturers' products now have their own CAS access integration. As long as they are configured, they can be connected to CAS without changing the code. This is for the future. Purchasing other software integrations can be very beneficial. Even if the newly purchased software does not support CAS access in the future, developers can also add this function. For them, this can be integrated as a standard function to expand their functions. Relatively speaking, their secondary development costs can also be shared without us paying in full.

The result
is this, more than 10 years of single sign-on and unified sign-on experience, a long time and a very simple process.
Along the way, I saw a lot and learned a lot.

In addition, if you want to know more about CAS, you can come to my CAS Chinese documentation site (http://www.cassso-china.cn) to take a look.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325375439&siteId=291194637