TechTalks Transcript
Web Access Management and Security
 Mark Bruhn [MB] |
 Howard Strauss [HS] |
 Phil Schacter [PS] |
February 22, 2001
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
MB: Welcome to the CREN Tech Talk series for spring of 2001 and to this session on "Web Access, Management and Security." You are here because it is time to discuss the core technologies for your future campus. This is Mark Bruhn, your CREN host for today. Our session is coming to you today with the support of the CREN member institutions.
Let me welcome Howard Strauss - in the other chair - of Princeton, as the technology anchor for Tech Talk. Howard is a well-known web technology expert and portal expert. Welcome, Howard.
HS: Thank you, Mark. I'm Howard Strauss, the technology anchor for the Tech Talk series of technology webcasts. My job as technology anchor is to engage our guest expert, Phil Schechter, in a lively technical dialogue that will answer the web access management questions you'd like answered and to ask those very important follow-up questions. You can ask your own questions by sending e-mail to expert@cren.net anytime during this webcast. If we don't get to your questions during the webcast, we'll provide an answer in the webcast archive.
Today's webcast will be all about the web access management. Of course, you understand that the web is that open marketplace where all ideas, products and services are freely exchanged, so there is little need to manage access to it. In fact, there are many organizations whose mission it is to keep the web open and free. For example, the FSF-the Free Software Foundation. On their website, they say, "Free software is a matter of liberty, not price. To understand the concept, you should think of free speech, not free beer." The point is that the openness of the web is a basic right on the level of the others in the US Bill of Rights.
But our everyday reality is that the web now gives users access to information that is private, copyrighted, licensed, privileged and otherwise sensitive or restricted. The ability to use the web to let students check their grades, allow alums to buy football tickets, have faculty access their retirement accounts and to let staff manage their budgets has become essential for the operation of all universities. Web access to news and weather may not require any web access management, but access to the financial and intellectual inner workings of our universities certainly does.
Traditionally, web access management was done by just having each protected application require user authentication with the use of an ID and password. For really sensitive systems, single-use passwords are required and many sensitive systems include increasingly complex levels of encryption, authorization management and personnel clearance. Treating each system as a special case has left many universities with a sea of different web management schemes and has left users screaming for some relief from the dozens of ID's and passwords that they need to remember. Most users keep those ID's in an unencrypted file on their insecure disks and often write them down near their computer screens where they are handy for their next use. The problem is rapidly becoming more acute with the advent of web portals.
To be effective, web portals require single signon, which is the ability to authenticate just once to the portal and have the portal authenticate to all systems to which it has access. One might suggest just using the same web access controls for all systems and applications to simplify this problem, but in fact, different systems require different levels of access control. While you might keep your will and family heirloom jewels in the safe deposit box, for example, you would not keep even a very valuable automobile there. As with so much else that we do in information technology, the solution is to plan our work, then work our plan.
The web access management plan we need is a high-level plan that balances our users' needs for easy access and control with the university's needs to have its data and systems secured from inappropriate use and its need to avoid some potentially nasty lawsuits. We'll discuss some of the issues you'll need to consider in putting that plan together in today's webcast of Tech Talk. Mark?
MB: In fact, if it's on the web, Howard - correct? - it's accurate, it's right and it may or may not be secure. We are pleased to introduce another new expert to CREN Tech Talks. Our expert today is Phil Schacter of the Burton Group. Phil is the Director of the Network Strategy Service of the Burton Group, where his work focuses on network security, platforms, messaging and electronic commerce. Phil has 25 years of experience ranging almost every type of application in the IT industry. He has authored industry reports on messaging, security and network topics. Welcome, Phil.
PS: Well, thank you, Mark and Howard, I'm very pleased to join you. This is a topic that I'm particularly interested in and I've been following it for about the last three years, since this category of technology has really been invented. And I'm looking forward to today's talk!
HS: So maybe you could just start by telling us what some of the key issues are involved in this web access management. What things should we be looking at when we think of web access management?
PS: Well, I think we start from looking at the business issues here. What are the risks, what are the services the business wants to expose through the web to its various users, whether these might be the investors of a corporation or for that matter, employees accessing various services through the web as the front door?
HS: Could you elaborate on that just a little?
PS: Sure. I mean, you gave a couple of examples. But, you know, if you're going to allow a student to access his grades or private information about him through a web portal, then it's pretty clear that there are privacy rules that your own institution's policies are going to require you to enforce. And then increasingly, I think we're going to see federal legislation that we step up those privacy rules quite dramatically.
HS: But a lot of people who are listening, I am sure, are going to be thinking that, well, for some websites we don't require this at all and for others, the kind that you're talking about, we require an ID and password. Why do we need some elaborate plan? Why can't we just put ID's and passwords on things and be done with it?
PS: Well, part of the problem is really the success of the web. There are so many more things we use it for today. You know, it used to be we would simply publish static information there that was public for anonymous access. But these days, you can surface just about any service that a business or enterprise wants to operate internally within their company. You can surface that and expose it through a website somewhere. So now we have hundreds of different applications and we simply can't give a yes or no decision. Different groups of users require access to different services.
HS: Where does this kind of plan fit in? I mean, is the kind of thing you're talking about, is this going to be done-it sounds like it's not going to be done application by application. I mean, is it going to be done at the very top of the IT organization, or because we're protecting university assets, is this thing even higher-level planning than that?
PS: In the early days of the web, going back even three or four years ago, it was really handled on an application by application basis. Every website and every application on every website made up their own rules. They had their own sets of requirements for whether it was a password or something stronger as a credential. The actual policies would be enforced and encoded into the application. Clearly, that doesn't scale, and it certainly doesn't scale to how organizations are using the web today.
HS: When you talk about how the organizations are using the web today, we alluded to web portals. Is that one of the things that's driving this more, a closer look at this web access management?
PS: In answering that, I think I have to put my definition of what I mean by web portal in play because people think of massive Internet portal sets like Yahoo and various marketplaces as being the definition of a portal. But I have a much simpler view of it in that it's really any point where I can aggregate multiple services that I'm going to offer a community of users.
HS: So if I can get to more than one application from a web page, you're saying it's a portal?
PS: I'm saying that clearly, that's a relatively trivial case, but the point is that if I have several applications or a group of applications that I service in different places in my organization and I put a menu up front at a website that gives people the opportunity to access any of those services, then I think that that is a portal.
HS: And when you're talking about services, you're obviously talking about services that normally you would have to authenticate to. Right?
PS: Not always. Yes, some of those could be for anonymous access and others could have much more stringent rules.
HS: But is there a web access management problem if we're talking about services for which you can have anonymous access to?
PS: Typically, if all the services are anonymous, then you probably wouldn't need to audit them or log the accesses or have any interest in establishing accountability for actions on the site.
HS: Okay, now, when we look at this thing that you're calling a portal - and I think that at least your description of a portal at least includes all portals. I mean, folks are going to argue that some of the things you would define are not real portals, and that's okay. The important point seems to be that we have one place where we can access two or more restricted services from. And so the issues becomes, how do we authenticate to this thing? Is that the issue?
PS: Well, the idea of identity and being able to verify identity is obviously key if we're going to apply some set of policies or rules that restrict which applications or services those users can gain the benefit of when they reach that portal. So identity and authenticating is really an important first step, a necessary first step if you're going to do effective access management at a web portal.
HS: A lot of folks talk about single sign-on when they refer to something like that. How does single sign-on fit in with what you're talking about?
PS: Single sign-on, we kind of alluded to this earlier. It's the scaling issue. You don't want to have to have a different identity and a different credential for every application that you access. And you also don't want to have every application programmer have to program in a different set of rules and a different method of authentication into his code. It's simply wasted overhead. It's important to have a shared infrastructure for authentication and access management, and this is a set of technologies that have begun to emerge in the commercial marketplace over the past couple of years.
HS: So you're suggesting that there are commercial companies that can provide you with single sign-on?
PS: Single sign-on in the context of web single sign-on. Being able to authenticate once and manage an authenticated session while you access multiple web services and applications over the duration of that session.
HS: Can we talk a little bit more about how that happens? How does that work? I mean, I come up to this web portal and I say, "I'm Howard," and I give them my secret password, SECRET. And I've got nine or ten applications. What goes on there?
PS: Well, the first thing is the website has to make a decision when it's going to prompt you for identity. Unless there's a specific customer login button that says GO HERE and log into the site, then typically it's only when you first try to access a resource that the system understands is being protected that it would prompt you to supply your identity information.
HS: Yeah.
PS: Your user ID and your credentials.
HS: Yeah, I believe a lot of portals do that right up front because if they know who you are, then they can customize themselves. They can tailor themselves to who you are. But you're making the point that they might do that right at the beginning, or they could do that when you try to access a restricted resource.
PS: Right. And the logic that's asking this question can sit in one of two places. You can insert an access manager in kind of a proxy architecture where it sits in front of the web servers or the application servers that are actually going to fulfill the request, or alternatively, you can have each web server that's represented by the portal have a plug-in in the web server that examines each request to serve up a page or to serve up a transaction. And it will ask the question then and determine whether it needs to require login or not.
HS: Do you have a sense as to which one of these things is better or worse or what some of the pros and cons are of going one of these two directions?
PS: The most dominant system in the commercial systems is the agent plug-in architecture.
HS: Did you say "ancient?"
PS: They're describing-�
HS: Did you say "ancient" or "agent"?
PS: They're described as being agents.
HS: Okay, fine. Okay, I thought you were making some statement about them.
PS: It's simply an [inaudible] code that's going to execute on every server that's going to get the benefit of this back-end shared security infrastructure. That's probably the most dominant approach out there, but there are occasions when that approach is problematic. First of all, not all products have written the code to support all possible web servers on all possible platforms. Sometimes you want to stick a proxy server in front of the actual system that's hosting the web pages that you're protecting. It could be a mainframe, for example, and very few vendors have plug-ins that will support mainframe-based web servers.
HS: One thing about this that I don't understand, really, and if we're getting into too technical detail, just wave me off and we'll go somewhere else. But it seems to me that if I authenticate to this thing and then it's going to let me authenticate to all kinds of other things or it's going to authenticate to other things for me, that it's got to have all my ID's and passwords stored somewhere. That kind of gives me an uneasy feeling. How does it do that? I mean, how does it do that in a safe way?
PS: Well, first of all, in order to answer that question we have to kind of talk about the architecture of how web applications interface with back-end database systems and different platforms that might be located in other places within the organization. Often what we put in place is we put a web server in front of our applications and that simply becomes the user interface. Then behind that, we'd have an application server and typically the application server uses a service account to represent itself to a back-end database system so that the database system that's providing the resource really knows about it by virtue of the service account that the application server is presenting. Now, there are some occasions where the application servers will actually do a proxy login that represents the web user and assumes that he has an account in the back-end system that you're going to be interfacing with.
HS: Right, but we're talking about storing my ID and password somewhere.
PS: Well, you only really - in that model, you would typically only have one ID and password. In fact, many of the users of these web portals really only have a defined existence in the system, they're only a defined entity at the portal itself. They're not defined to the back-end Unix systems or to the back-end mainframe systems.
HS: So they're just defined to the portal and then they're just given authorization to other systems?
PS: Then by virtue of being able to go to the application server to execute the transaction, by virtue of the fact that they're being allowed to do that, they basically have the entitlement.
HS: Right, okay. So because you're allowed to do it, we don't care who you are. The fact that you're allowed to do it means you're allowed to do it.
PS: You've externalized the policy checking from the actual application program that's running back there and you've put it in this layer that sits in front of it and protects it.
MB: That would mean, then, so that the applications have to be smart enough to know if the user's accessing them via the portal or stand-alone or they can't be accessed via stand-alone at all.
PS: That's quite true, and many of these applications have been written specifically for a portal architecture design.
HS: What happens when a portal, though, accesses a system that's outside the university? Where, I mean, you have a lot of control over what the person's ID and password, etc. and so forth, are inside the university, but take a very common kind of thing. I want to go out and access my TIAA/CREF stuff through my portal and TIAA/CREF tells me I can't have the ID HOWARD because somebody else has it. So somewhere, to get into that system, I need a different ID and password. This thing's going to store those things away somewhere?
PS: Well, this is something that the industry really doesn't have a good standard for how to deal with affiliated websites that involve going outside of one company's boundary into a separate company. Today, the state of the art is that these have to be bilateral arrangements where you basically negotiate the protocol that you're going to use to transfer information about an active user and his credentials to the receiving site if they're going to provide him with a service. Now, this is something that we expect to change. There's work that's going on in the standards community to define XML-based ways to allow these affiliated sites to negotiate a single signon session and then to deliver services to the user that's been authenticated at the site of the associated institution. But we're not there yet. These systems are not in commercial operation yet.
HS: Is that the kind of work that that group called OASIS is doing?
PS: Yes, actually, OASIS picked up the ball on this one. The original work on these specifications was done by two different private industry groups, one called S2ML or Security Services Markup Language-which was chartered by Netegrity and several of their partners-and another one called OFFXML, which again dealt with applying XML to the problems of authentication and authorization. And that was from a company, Securent Technologies and a group of companies that they worked with. But those two groups have come together through the OASIS technical committee on XML-based security standards for the Internet and that's where we expect to see this kind of interoperability spec emerge that will allow one site to assert the identity of a user and have that assertion honored by an affiliated site that's going to provide a related web service.
MB: I have a question about that, but let me first remind our listeners that this is probably a good time to send in questions to expert@cren.net. Phil, how optimistic are we, should we be that services like for example, the subscription New York Times Online or Wall Street or those kinds of external services will then make use of such a standard so that a portal can in fact be that single sign-on service.
PS: There's so much commercial value to being able to aggregate services that once we have effective technologies and standards to support it, I think the commercial adoption rate is going to happen very quickly. The thing that makes me real optimistic that the OASIS effort is actually going to be successful is that, you know, we're starting with a couple of very solid specifications that went into the process in the December-January timeframe and with that, over 70 companies have kind of joined the process, including the top ten or 12 companies providing these products to the marketplace. So there's a very strong industry commitment to get this spec done. They have a very aggressive timetable. I believe that they are looking to deliver the first drafts of the spec, official drafts of the spec, in early June of this year. I'm expecting to see the first commercial implementations before the end of the calendar year. So I think this is going to move very quickly.
HS: That's the first commercial implementation of SSML or what exactly are we going to see there?
PS: Well, it isn't clear what the OASIS working group will call the final standard. The two that went in were called S2ML and OFFXML.
HS: What was the other one?
PS: OFFXML and S2ML. Those are the two starting points, and they're debating what the final [inaudible] standard will be called and I don't think they've made a determination yet. But the benefit is that we will have an XML spec that not only different security vendors of these technologies will support, but this will also become a key technology for how application services themselves interact with the security policy infrastructure that these products represent. In effect, it becomes an XML way of tapping into security services that would not require an API.
HS: Um-hum.
HS: That sounds like a very interesting thing. Another group that's doing stuff that sounds similar to this is the Shibboleth Project. Could you say something about that? Does that fit into this thing in some way?
PS: Well, I don't know a great amount about Shibboleth but I do know that part of the problem, at least, it is trying to solve does really fit into this category. The idea of having a user authenticate at one institution and on the basis of that authentication, be granted access to services that might reside at a different institution. In addition to that, they are also trying to establish a test infrastructure for this community of institutions, and there's also some issues around privacy and individuals being able to control what happens to information about them. And that last point, that is not an area where the OASIS group is working on at this point.
HS: Um-hum.
PS: I think it is certainly a priority requirement. But that problem is not going to be solved by virtue of the work that that industry group is doing.
HS: Okay, we just got a question by e-mail. Thank you for sending it in. Let's get some more in! But we got one in from Scott Garrison at Chapel Hill, at University of North Carolina. His question's a little bit long, but I can read it fast here. But it's kind of interesting. He says, "I work in an academic health and science library with the following problem: we and many other entities around our large research university campus each license different commercial databases for different sets of users on campus and around the state. There is no good way of authenticating all university users to the appropriate resources in place as some users have a university user ID, some have a library user ID. Others need proxying, etc. and so forth. It does not seem possible for our university to create one authentication system to manage authentication and access control for all of the licensed resources on all of our users' use. Can you comment on standards that are available and feasible for a larger organization with so many classes, license restrictions and potential locations?"
PS: This probably is typical of many organizations, not just, say, university institutions. Over ten or 20 years, we inherit so many different kinds of technology and applications and the norm in the security world generally has been that each application builds in its own security. So now you have this problem that our listener has raised, that you've had a proliferation of identity information and credentials that go along with that. You know, the dozen or two dozen passwords that you have to maintain.
The long-term solution, of course, is that the portal architecture allows us to adapt the applications and remove that security logic. Of course, there's a big investment in existing applications and it will certain take a long time for companies to re-instrument the back-end applications. In fact, some of the applications may be code that the institution has no direct control over. We are seeing some tactical technologies that are intended to bridge these many different signon environments that accomplish things like having a single identity and synchronizing a credential across many different back end systems and applications.
This is something that we used to look at under a class of product called Enterprise Single Signon. More often than not, what they involved were password synchronization technologies. Now, a new generation of product is beginning to emerge that some people refer to as e-provisioning, and then these e-provisioning products, what they're attempting to do is to establish a single focal point for administering and trading a new user. You register a user and then based on some policies or profile, you create the accounts for that user in some variable number of back-end systems and applications. So you force the creation of an account, you force the adoption of a common form of credential in these back-end systems and that becomes one way of maybe not eliminating all duplication, but at least of reducing the number of signons that you might have to experience here.
HS: We have another question from somebody just down the hall from me, Dan Oberst at Princeton, here. He could actually just wander in the door here and ask the question himself, but I'll read it to you. Dan says, "Microsoft, Apple and Netscape have built ID password keyrings or passports that store the ID and password locally on the machine for use on various systems. YODLI does the same things but keeps these on a server to let you check your bank, credit card, frequent flyer miles, etc. What's wrong with this? It works, and while all your information is stored somewhere-locally or on a server-having a universal credential that works in multiple places just presents the risks with all the eggs in one basket. Compromising the ID password is the same as someone getting all the ID password information form a file." Want to comment on keyrings?
PS: Well, the only negative with any kind of caching of credentials on a single machine, of course, is that you lose portability. And in the bigger model where people are coming into a portal as a web interfaced set of services, then they really want independence of being able to come in from pretty much any location. Now, you do have things like Microsoft has Passport technology that is cached at a server, but at least the initial round of uses of that, it tends to be a subset of more commerce-oriented sites that would subscribe to that password system and once you authenticate to Passport, it understands the context of your authentication and will honor it as you move from one commercial site to another. Those initial server-based systems really haven't gotten widespread adoption yet and they aren't based on standards, at least not at this point in time.
MB: I'm actually reminded of a recent event where the database of a large vendor was compromised and in that database were the user names and the passwords of the customers of that service. It comes to mind because we, in fact, got calls here at Indiana University from a couple of individuals that claimed that their university credentials were compromised because their password was the same. How big of an issue is that now?
PS: Well, many websites, that's the weak link is the file that contains the credit cards, unencrypted, of course. Living dangerously, of course. We prefer to keep our private information in a form that isn't having to be stored in lots of different locations where you really have no control over the rigor that those sites are applying to the protection of our private information.
HS: But does biometrics solve any of these problems?
PS: Well, in effect, biometrics could actually make the problem worse. If the implementation-�
HS: That'd be great!
PS: --the encoding of your fingerprint has to be stored in a server somewhere, and that one gets compromised, then you can't simply be issued a new fingerprint. And this is why we see hybrid strategies emerging where you find a way of locally caching the biometric information so that it never leaves your personal control. For example, storing the encrypted encoding of the fingerprint on a Smart Card, and as long as you have possession of the Smart Card and you can only unlock it with some password that you enter, then you can never really lose control over that encoding of your fingerprint.
HS: But then what does a Smart Card send?
PS: The way authentication would work in that model is that the sensor would either be tied to the same card or the sensor would be on the same machine that the Smart Card reader is on, and once you type in the PIN to unlock the stored encoding of the biometric signature, it would then match it against the version where you depressed your finger on the local sensor. And if it got a match, then typically it would unlock a different credential, probably a PKI cert, and the cert itself would be the thing that ended up being presented back across the network.
HS: This proxy scheme that you described sounded a little bit like a firewall. Is it? And how do firewalls fit into this whole scheme of doing web access management?
PS: Well, firewalls will still have a role in traffic filtering, but based on very high-level attributes like location and IP address. They simply didn't have the granularity to allow us t make decisions regarding hundreds of different application services, each of which might have its own unique access profile. And you're right, you know, putting a proxy server in front of the web and application services that you want to control access to is kind of like a firewall, but very specific to the web paradigm and the requests that it's examining aren't typical TCP application streams. It's examining an HTTP request to serve a page or to invoke a transaction.
HS: When somebody is using a portal and they're going from page to page, place to place, whatever, it seems like the stateless web somehow has to - somebody has to maintain state. Somebody has to know as you go from place to place that it's still you. Do these web access management systems also maintain state in some way?
PS: You're absolutely right, HTTP is a stateless protocol and they do need to maintain state. Different commercial products have tried different strategies over time, from caching the state information at the server to Java applets that will-�
HS: Cookies to whatever.
PS: --create memory tokens. But they've all ended up coming down to the need to at least maintain a form of cookie in memory, a transient cookie that contains even a very minimal amount of information, enough that can uniquely identify the session and cross-reference back to more detailed information about the user that would be cached at the server. So they've trimmed it down so that they're trying to tread a fine line between some of the privacy concerns around cookies, yet needing to have this basic identifier that they can uniquely link back to the session that can communicate whether this particular session has been authenticated yet or not.
HS: Would those systems also include things like - or maybe it's an application design thing - but what about machines that just get abandoned? Would somebody doing this kind of web access management put in all kinds of time-outs and things like that, things to un-authenticate you?
PS: Yes, you're absolutely right. One of the policies that would be specified is a time-out policy. There are also, if you're dealing with particularly high-value transactions, what will also sometimes happen if you may authenticate at one level using a simple password and get the benefit of some set of services. But at the point where you want to transfer money out of your bank account into some other account, then it may prompt you for a second authentication which may involve a different credential or some different piece of information you have to know.
HS: When you're using one of these systems, I assume you're using a web server and you're using SSL. Is that required, or is there some other scheme?
PS: I find that often the two are used in combination, but mostly SSL is not required. Now, at one point we thought we could use SSL and its characteristics to give us that unique identity without having to drop cookies, but it turns out there's a lot of performance overhead having to constantly recheck the state of the SSL session and it just turned out that, as the systems were being benchmarked, that the only real solution, even when using SSL, was to use it in combination with a basic in-memory cookie [inaudible] session management algorithm.
HS: Do you think it will be a good idea for universities to just have all their systems use SSL, just as a matter of course?
PS: There are probably some performance issues.
HS: But everything gets faster if [inaudible].
PS: [inaudible]. I mean, SSL is getting faster and we're [inaudible].
HS: And the hardware getting faster and [inaudible].
PS: [inaudible] that make them run faster. Probably every time you're dealing with information that you must insure it's kept private, you are going to have to start using SSL.
MB: Let me ask-�
PS: Either you do it on your own volition, or eventually you'll be legislated to use encrypted channels to protect that information.
MB: Related to that, let me ask a general question. I know that your philosophy on this and mine are probably the same. I just want the Indiana people here to hear you say it.
HS: You're really taking advantage of this broadcast here, Mark!
MB: Who makes that kind of decision? Decisions about, for example, the level of authentication required for a particular application. Who makes the decision whether SSL is required and accepting of the performance hit?
PS: Well, the different stakeholders here. Certainly, there's an owner of the service that is responsible for the integrity of the service and the information that service is working with. And that's probably where the primary responsibility should be, to require from the network provider, the provider of these computing services, the right kind of security attributes and the technology. You'll run into situations where the legal department will insist upon a certain level of security, or the audit department in a financial institution has a great deal of influence on the security characteristics of the portal or of any service that that institution's going to be offering.
MB: So my guess would be, then, that the technicians involved in the development project and what-have-you would certainly have some opinions about that and could certainly speak to the technical performance issues. But generally, it's not really a technical decision to make.
PS: It's a business decision and it's a management decision. You can advise the organization of the risks involved, you can advise them of the benefits and the costs of the technology, but the bottom line is that a business decision has to be made, that there's some liability or risk that needs to be protected against. The other reality, of course, is that security can't get in the way of business either. You do have to have this compromise or this balancing of the two objectives. Security's job isn't to prevent the organization from doing business and from interacting with the users that need to use its services.
HS: It seems that one of the difficulties in doing this-I agree, it's not the technicians' job to decide what the level of security it, but that often the user department really doesn't have any knowledge of what the information technology risks are. They don't know what the risks are in having something online, so it's very difficult for them to make that decision, too. I mean, I think that they'll often say, "Make it secure."
PS: It's advisory. You have to educate your internal customer to what the risks are. If you think that there's an error, there needs to be a way in your organization of exporting the issue so that the decision is moving up to a level in the organization that can understand both the technology risks and the business risks involved.
HS: When we talk about these web access management systems, could you talk about some of the companies who are leading in this field?
PS: Sure. There are dozens of different vendors in this space now and more arriving every day.
HS: But I assume that they make products. When you say, "in this space," they make products designed to do different things here.
PS: There are certainly some variations. Obviously, the vendors are trying to address as broad a market as they can, so the technologies are general-purpose. They will work with most of the leading web servers and most of the leading application servers. Some of the leading vendors by market share today are companies like, let's see, the top three would probably be Netegrity with their SiteMinder product, the Entrust organization with its GetAccess product and the Tivoli Systems division of IBM with its SecureWay Policy Director product.
HS: Could you say just a couple words about each of these things, whatever their products do?
PS: I also want to - there are several other vendors I want to mention.
HS: Oh, sure.
PS: Other vendors in this space are Baltimore Technologies with their [inaudible] product. Integrity has a product, I believe it's called AssureAccess. Accent has a product in this space, OpenNetworks. Vasco Data Systems. So there's really-Securent Technologies is certainly up in the top four or five in this market. And I've probably forgotten-�
HS: Well, we have the whole list on the website, actually, for folks who can't take notes quickly enough. They're all on our website, and in fact, there's links to a couple of these themselves so you can go out there and take a look at them.
PS: Many of these products are relatively mature now. The basic genesis of the products began with technology that's been refined over several years, three to four years and several release cycles. So these are mature, stable products. There's a constant-it's a very active, competitive market, so there's a constant race to upgrade future functionality so it's a very healthy technology marketplace. A lot of innovation that's happening in this area.
MB: I'm actually going to have to take control back.
HS: No! You can't!
MB: And ask Howard, any final questions or comments?
HS: No, actually you're early!
MB: I am?
HS: Yes! We want to point out here that we actually have lots of time. Although we say it's going to end at 45 after, it never does. No, we probably have time for another - maybe another three or four questions here.
MB: Well, then, let's carry on! And in fact, I'll read this next one.
MB: It's from Andrew Corty who, in fact, is the principal security engineer in my office. And Andrew writes, "If SSL is not used for all transactions involving a single sign-on service, what is to prevent session hijacking by stealing the cookie off the network wire? Checking the IP address may help, but especially in a university environment, stealing IP's is not impossible. Kerberos gets around this problem through the use of authenticators, but I don't believe web browsers have such a feature."
HS: Phil?
PS: That's a good point. There could very well be some potential hijacking situations. Obviously, the vendors in this space also have some very strong security architects, so I would be very surprised if there aren't some checks and balances that would be there strictly to catch the potential hijacking. But if you could sniff the IP address, then you could also capture the cookie. The cookie actually isn't the equivalent of a Kerberos token, though. All it's really doing is providing some attribute information about the session so that you can relate it back to the last time you spoke to that session. So I guess the answer is that there might be some potential there, but I believe that there are checks and balances that would preclude that from happening most of the time.
HS: Okay, are there some industry standards that these products that these companies produce, are there some industry standards that they're using?
PS: Well, there's a lot of different technologies that go into an access management system, including a lot of identity management functions. They tend to rely a lot on LDAP directories to get information, to maintain information about users and attributes about those users such as what is their business or management role, and use that information when they're mapping an access policy to a role.
In authentication, these systems will support many different forms of authentication credential, not just simple passwords. And in that space, probably the most common beyond password is supporting different PKI systems so that they do support and implement the PKI standards. In terms of being able to create these single signon sessions between companies, the only thing that we can really look forward to in the area of the standard is the work that the OASIS technical committee is pursuing at this point. And that's probably [inaudible] the three key standards.
Many of the systems internally are achitected around technologies like [inaudible]. They also implement some of the technologies like [inaudible] authentication modules which involves some of what Sun has done in this space and also standardize through the Open Group. There are some bits and pieces of standards out there. There is an authorization API that was standardized through the Open Group a couple years ago, but hasn't really seen much deployment.
HS: Okay, just coming back for a second to - you mentioned that there were three companies that were sort of the leading companies here. What kind of products are they selling? Are these single sign-on products, or what kind of things are they?
PS: Well, I think most of them today would position themselves as being portal access management products. One of their benefits is that they can create this single signon environment, but another big part and another benefit, I think, is they support this ability to mix and match various different authentication protocols so that they provide an authentication framework for companies that lets them kind of move between different forms of authentication when they choose. But the other key area of functionality here is something we refer to as a Privileged Management Infrastructure. And a Privileged Management Infrastructure is where you physically encode the rules that say now that I know who the user is, now what will I let him do at my website? Which pages will I let him get to? [inaudible]�
HS: That's a kind of authentication scheme?
PS: More of a-�
HS: Or authorization, I meant. Sorry.
PS: More of an authorization.
HS: Yep.
PS: An authorization scheme, but with a very web-focused point of delivery. The policy enforcement point typically is the web server or the application server that's trying to make the decision of whether to allow the request or not.
HS: Looking ahead, how do you see this web access management area evolving? What's coming down the road now?
PS: Well, I think that there's a broadening of the role of these products. The web paradigm is obviously very important. The idea of exposing and aggregating services through portals is really catching on in many enterprises, in the context almost of private portals. So I think that these are becoming really strategic parts of the security infrastructure. They're probably more important than whether it's Kerberos or PKI that we're using as our authentication mechanism underneath these systems. And I would see that that role would extend further and deeper into the organization. It will be supported on more platforms. It will get involved more intimately with the local security managers on the Unix systems and the NT and Windows 2000 systems and the mainframes that sit behind them. So these products may eventually become the answer to enterprise single signon over time. Right now, it's a young market that's maturing and it will really take time for them to make the right investments and the right kinds of partnering relationships to really expand further and deeper into the organization.
HS: Okay. Mark?
MB: Okay. Any final questions or comments>
HS: I have one final question for you, Phil. For universities who are listening out there, if they want to know what they should do right now - besides if they're living on the east coast, get home, because there's a big snowstorm out here! But if that's not what they're going to do, if they're concerned with web access management, what are the first steps they ought to be taking?
PS: Well, if you're opening up services through the web as kind of a front door to your organization, then you really need to design security into your architecture up front, at the point where you're going to deploy these web portals. To try to do it afterwards, you know, as kind of an afterthought really defers the problem and makes it worse. So put it in your design and your architecture plan early in the game, before you actually start to roll out new websites. And given that there's already a lot of existing application and web data out there, you know, one strategy might be to put proxies in front of some of the existing sites. You don't want to disrupt what you've got out there that's working, and that's another case where I think the proxy architecture has a strong benefit.
MB: Very good! Most excellent stuff! It's time for our closing notes. First, I want to thank all of our web participants for being with us here today. Be sure to plan on joining us two weeks from today, on March 8, when our special guest expert Judy Bueher, who is chair of the Web Accessibility Initiative of the W3C Consortium, she will be sharing her suggestions and recommendations on web accessibility. We hope to apply some of her suggestions into that event, although we don't quite know what that means yet at this time!
Many thanks to all the institutions who support these Tech Talks. Thanks to all the Tech Talk folks who helped us make this event possible today. A very special thanks to our Tech Talk expert, Phil Schechter. As always, to technology anchor, Howard Strauss; to Terry Calhoun, Tech Talk web guru; to Jason Russell, Gayle Terkeurst and the support team at Merit Network; to Susie Berneis, audio file transcriber; and finally, our thanks to all of you for listening in. You were here because it's time.
HS: I'd like to thank Mark for filling in for Judith and for doing such a great job today. Thank you very much, Mark.
MB: Thank you so much. It was fun! Bye, Phil. Bye, Howard. Bye, all.
HS: Bye-bye.
PS: Thank you, I've enjoyed our talk today.
HS: Right. Bye-bye.
END OF WEBCAST
