| Internet2 Middleware WebISO |
Document Version: Draft 02 |
| Authored by: Chad La Joie (clajoie@vt.edu) Edited by: Russell Tokuyama (russ@hawaii.edu) |
Date Submitted: 7/28/2002 |
With the backdoor method the delegate system completely circumvents the destination system's API and directly accesses its data store in order to retrieve the information necessary. If the user is expected to interact with the destination system the delegating system will usually setup a session for them in the destination system and then redirect the user to the destination. This model requires that the delegating system have intimate knowledge of destination system.
While it helps to think of WebISO and privilege delegation systems as logically different systems, they are almost always implemented within a single software package. It may however be of benifit to look at the differences of these two systems before discussing how they work together. First, pure WebISO systems are designed to only be used with web applications whereas privilege delegation systems are meant to work with any system which has the concept of user based access control (though in practice most privelege delegation systems focus on web applications). Second, WebISO systems are focused on providing applications with assurance that a user is who they say they are, that is, that they have been authenticated. Most delegation systems are not so much concerned with this aspect as they are with the ability for one system to use a principal's privileges on the destination system, though most delegation systems do take into account some level of authenticity checks. Third, WebISO is concerned with the security restrictions that may exist between web applications, for example if one web application requires a userid and password for login and another requires smartcard and pin for login, the WebISO system must be able to understand the difference in these two security realms. Again, delegation systems aren't so much concerned with how the person is authenticated, or supposed to be authenticated, between applications, it is instead concerned with the person's access to restricted resources/functions.
So how do WebISO and privilege delegation systems work together? The following example with help frame the discussion on this. Suppose a user is required to enter a user id and password to access you portal system. In order to display all the information the university would like to in the portal it must have access to both the user's email account (to get the number of new messages) and the user's enterprise information system account (to get thier list of classes). The mail system requires a Kerberos id (not the same as the portal user id) and a ticket to access it while the enterprise information system requires a numerical PIN and password to access records. Assuming you wanted to integrate all these systems you would have at least two issues (probably more) to overcome. First, how do you take the portal user id and translate it into the principal ids required by the other systems. Second, how do you access the others systems, on behalf of the user, to get the information you need.
As mentioned above privilege delegation framekworks provide the answer to the second question. Through thier numerous mechanism they can access the destination systems either directly as the user by masquerading them or using some proxied credentials or inderictly by using a backdoor or an established trust relationship. A WebISO system provides the means to answer the first question. It's concern with user authenticity, especially if it supports the concept of security realms, means that it's well suited to translate one principal id to another. If your privilege delegation system can interoperate with your WebISO systems, and it's likely that it can, then the delegation framework can simply request the translated ids as it needs. Once it has the ideas it can employ any of the mechanisms mentioned above to gain access to the user's information on the destination systems. If the method choosen is the use of proxied credentials it's likely that WebISO will be the one to construct the credentials used by the delegation framework.
With the ability to delegate user privileges to other systems the question of security should be in the forefront of everyone's thought. This section looks at some of the security risks associated with this framework in general as well as those security risks inherent to each method of delegation.
Like most authentication/authorization systems it's important to know who you're talking to. If you are not checking the identity of all the systems involved (delegate checking the destination system's id, etc.) then you're leaving yourself open to a man in the middle attack. Also, this check must require something stronger than just an IP address check or some other easily spoofed set of information. Instead things such as client cert verification with SSL connections can be used. Other, simpler to implement, means might include things like having the delegate system "log into" to the destination system. That is, the delegate system presents a userid/password pair of its own.
In addition to verifying the identity of those applications that are being communicated with, there is the need to ensure that no one else is listening in on the conversation. If your delegate system and all the applications it uses are not using a secure network then it should assumed there are hostile applications listening to all your traffic. Securing your traffic can easily be done by using SSL assuming your delegate system uses protocols that can be tunneled over SSL. If it does not then each system, the delegate and destination, should encrypt and decrypt each message as they send and receive.
A delegation framework's handling of sessions on the different destination systems can also be the cause of a potential security risk. When a delegate system accesses a destination system it may create a session which must be managed in the same fashion as any other user session. Normally a session would end when a user issued an explicit log out command to the application, but because of the nature of delegating frameworks the user can not issue this command to all the destination systems for which a delegate system may have created a session on. Many delegating frameworks have an ability known as cascading logouts where the user's explicit log out command issued on one system is sent to all the destination systems on which the user has a current session. If this process isn't handled correctly, or isn't done at all, session may remain open on the destination and run the risk of being hijacked. This alone could be disasterous if, for example, the attacker managed to hijack a privelaged account on your enterprise system, however the risk is compounded by the fact that the attacker may be able to use this session to create sessions on other systems by employing the delegation framework.
If your delegate systems uses the masquerading method, one of the biggest security threats to be aware of lies with the delegate systems. In order to masquerade as the user these systems must store the user's principal and credentials somewhere. If this location is in a file on the disk then some one who compromises the system may be able to read the file and harvest the information in the file. Another common place to store this sort of information is in the memory where it's "safer". The problem with this is that by default many applications are compiled with debugging information which numerous tools use to read memory that the application is using. Java, for instance, provides a very nice API that gives access into the JVM's memory space; thus, allowing debugging tools to do just that. Again, if the system has been compromised the attacker could most likely easily install these tools and read the information right from memory.
Most applications that use the Masquerading method often claim to protect against this threat by encrypting the information when they write it to file or store it in memory. The fallacy here, however, is that this offers additional security. In order for the delegate system to read the encrypted data it must have a way to decrypt it. If the application has access to the key needed to decrypt then the attacker that compromised the system does as well. The only additional security that is gained by encrypting the information is that the attacker now needs to figure out which encryption method is being used. Once that's done she will be able to read the information just as if it was in plain text.
Unfortunately there is no good way to solve these problems. Some programming languages have features which help; Java's sand boxing features for instance, however, none of them offer fool-proof solutions. For these reasons, the masquerading method is not recommended for delegate systems where security is of great concern.
The major problem with the trust method is the fact that the delegate system's access to the destination system is entirely based on the identity of the delegating system. As was discussed in the general risk section this can be a problem if the destination system simply takes the delegate system at its word or only checks information that is easily spoofable (MAC address for example). As discussed above, probably the most secure solution to this problem is to make sure that both delegate and destination systems use SSL to communicate with each other and enable client certificate verification. However, this adds a lot of overhead to the systems, especially during the initial setup of the connection. Some of this can be overcome with the use of a persistent connection, but there is still a going to some overhead for maintaining that.
Another risk associated with the trust method is administrator negligence. If a system in the trust network is compromised, it is possible that the administrator of the compromised system may not inform the administrators of the other systems in the delegation framework. If that occurs then the attacker may now have access to all the other systems in the trust network. This can be taken care of by good communications and, if your delegation framework has the ability, revoking trusted access from the compromised system.
The biggest threat inherent in the backdoor method is ignorance. If the backdoor method is used and the person implementing it does not have a firm grasp on the inner workings of the system it is possible they could open up security holes. For instance, referring back to the first general risk, if the destination system doesn't check the identity of the other system then any external system may be able to gain access to the destination system.
This is probably the most secure of all the methods discussed here. Assuming that all the general risks have been addressed there is only one other issue to consider. Each ticket that is issued by the central authentication/authorization system should be unique and have a limited lifetime in order to ensure that replay attacks can't be launched immediately or in the future should an attacker get access to that ticket.
This section is still in progress, however, here are some links to the systems currently planned for case study review.
A couple of papers on authPortal.
AuthPortal, version 3, overview
Towards a WebISO Model