4 Security limitations for current scenarios The current Web-sso scenario is a relatively simple prototype, mainly used to demonstrate the concept of SSO and illustrate how SSO technology is implemented. There are many aspects that need to be perfected, in which security is a very important aspect. As we said, one of the main purposes of using SSO technology is to enhance security and reduce security risks. Because SSO is used to reduce the number of passwords passed on the network, the risk reduction is obvious, but the current scenario has other security risks. Because cookies are unique credentials for a user to log in, the protection of cookies is an important part of system security:
- Length and complexity of cookies
In this scenario, the cookie is given a fixed string (my name) plus the current timestamp. Such cookies can easily be forged and guessed. A malicious user who guesses that a legitimate cookie can be used as a logged-in user, any resource within the scope of the access permission
- The efficacy and protection of cookies
In this scenario, although the password can only be transmitted once enough, cookies are often transmitted in the network. Some network probing tools (such as sniff, snoop,tcpdump, etc.) can easily capture the value of a cookie. In this scenario, the protection of the cookie during transmission is not considered. In addition, the effectiveness of cookies is too simple to check whether the origin of the cookie is the original owner of the cookie, which means that the normal user and the user who copied the cookie cannot be distinguished.
- When one of the applications is not secure, all other applications are subject to security threats
Because of SSO, it is easy to break other applications that are in the same SSO protection when an SSO application is compromised by a black guest.
These vulnerabilities are considered in a commercial SSO solution, providing relevant security measures and protections, such as the complex reading of Sun's access Manager,cookie and the protection of cookies in a very good way. In addition, a solution to some of the security measures is also given in the Opnesso (https://opensso.dev.java.net) Architecture Guide. 5 functionality and performance limitations of the current scenario in addition to security, the current scenario requires a lot of improvements in both functionality and performance:
- The login authentication mode currently provided is only one: username and password, and in order to be simple, put the username and password in memory. In fact, the source of user identity information should be a variety of, can be from the database, LDAP, and even from the operating system itself, a list of users. There are many other authentication modes that are indispensable for business applications, so SSO solutions should include a variety of authentication modes, including digital certificates, Radius, Safeword, Membership,securid, and many more. The most flexible way should be to allow pluggable Jaas frameworks to extend the identity authentication interface
- The filter we write can only be used with the Java EE application, but not the SSO service for a large number of non-Java Web applications.
- When you apply filter to a Web application, you need to modify and redeploy every application on the container. The more popular approach is the agent mechanism: To install an agent for each application server, you can apply SSO functionality to all applications in this application server.
- The current scenario does not support SSO for Web apps that are located in different domain. This is because when the browser accesses the Web server, it only brings those cookies that have the same domain name as the current Web server. There are many other ways to provide a solution for cross-domain SSO, which is not much to say here. Sun's access Manager has the ability to cross-domain SSO.
- In addition, the performance issues of filter are also important. Because filter intercepts every request that conforms to the URL mapping rule, it obtains a cookie to verify its validity. This series of tasks is to compare the consumption of resources, especially to verify the validity of the cookie is a remote HTTP call to access the Ssoauth authentication service, there is a certain delay. Therefore, the performance needs to be further improved. For example, in this example, if you change the URL mapping from ". JSP" to "/*", which means that the filter works on all requests, the entire application becomes very slow. This is because the page contains a variety of static elements such as GIF images, CSS style files, and other HTML static pages, the access to these pages through the filter to verify. In fact, these static elements do not have any security requirements, should be judged in the filter, not to check these requests, performance will be much better. In addition, if you add a certain cache to the filter, and you do not need every cookie validation request to go to the Remote Authentication service, performance can be greatly improved.
- In addition, the system needs a lot of other services, such as the timely removal of useless cookie mapping in memory, and so on, is a serious solution to consider the problem.
Web-sso's Safety
