Web services have emerged in recent times as a key technology for the development of loosely coupled, distributed, reusable software components. Much of the rhetoric surrounding web services has focused on the ability for organisations to expose parts of their business on the internet. Web services, on the other hand, are increasingly being used within the enterprise to develop application components that can be integrated with disparate and heterogeneous systems. In particular, web services are providing a way to "front-end" legacy applications, as well as allowing applications developed for competing platforms such as Java 2 Enterprise Edition (J2EE) and .NET to talk to each other.
The web services paradigm creates interoperability by reusing existing web infrastructure. This approach also simplifies the development and deployment of web services, making them an ideal platform for rapid integration. The looming question on security of web services results in several initiatives within various standard bodies to address these concerns. As yet, no clear picture has emerged about what should be done to provide a security framework for web services that provides cross-platform interoperability and security, without the need for new infrastructure or protocols.
This article demonstrates how to create a Single Sign-on environment for Enterprise J2EE and .NET web services using Active Directory that meets this goal. It provides true Single Sign-on, which requires the user to log in to their desktop only once, and supports delegation and end-to-end security. We show how this capability can be deployed by organisations straightaway, by reusing an existing infrastructure, and without changing any code.
Before reading this document, you should have a basic understanding of web services (including XML and SOAP), security concepts, J2EE and .NET. See Links & Literature for more information.
Scenario: A Financial Trading Platform
To illustrate the problems of providing a Single Sign-on environment for J2EE and .NET web services, we will consider a scenario involving a funds management company Xerxes Mutual Ltd. In this scenario, there are two main applications used by two different groups within the organisation:
A commodity trading application. This is used to manage a fund that invests in commodities, providing pricing and analysis to the fund managers.
Retail brokering application. This application is used by brokers who are selling units in different funds.
The company acquires a cash management fund, Short-Term Capital Management, Inc., for the purpose of offering as a retail investment, and to provide finance to other funds managed by the organisation.
The business units within Xerxes Mutual wish to integrate these applications. They want the commodity trading application to have access to information from cash fund such as the price at which it can borrow various amounts in different currencies for different periods. Furthermore, they also want to have the ability to borrow funds automatically when certain criteria are met. The retail brokers want to be able to buy and sell units in the cash management and commodity funds, and have access to up-to-date information about these funds' performance.
These applications have all grown organically and use a plethora of different technologies. The commodity trading application is a web-based J2EE application using BEA WebLogic and running on a Solaris operating system. The business logic is implemented as a J2EE web service using the Sun Web Services Development Pack (WSDP). The retail brokering application on the other hand has been developed with Microsoft infrastructure, using an ASP.NET application hosted on IIS. Lastly, the recently acquired cash fund provides a .NET web service with pricing, lending and trading functionality. Both Xerxes Mutual and Short-Term Capital Management are running Windows 2000/XP desktops and using Active Directory on Windows Server 2003. Fig. 1 shows how these services will interact.
Fig. 1: Scenario architecture
At face value, the task of integrating these systems seems non-trivial. Each system is using a different application server platform, and running on different operating systems. Since the organisations have only recently merged, there is also the issue of how identities in one organisation can be used to authenticate to services in the other.
However, a common thread is the use of HTTP-based web services to implement the solutions. As we shall see, this commonality, and the reliance on Active Directory to authenticate users on the desktop is all that is required to provide a secure, Single Sign-on environment to all components in our scenario.
Web Services
Web services are based on the principle of using XML messaging over standard web protocols such as HTTP. This provides a lightweight communication mechanism with which any programming language, middleware or platform can participate, making interoperability easier to achieve. A key idea in the web services strategy is the reuse of existing infrastructure and protocols wherever possible. In this section, we briefly outline how web services are supported in the J2EE and .NET platforms.
Web Services Using .NET
.NET is Microsoft's platform for distributed computing, developed from the ground up to incorporate web services. It provides a simple mechanism for specifying web services interfaces via method-level metadata. .NET is language independent. Developers using languages such as C# or VB.NET, developed specifically for the .NET Common Language Run-time (CLR) with Microsoft's Visual Studio .NET development environment will be able to make the most of the .NET features.
Server components for web services can also be developed by means of Microsoft's extensions to its Active Server Pages technology ASP.NET.
Web Services Using J2EE
The J2EE platform was designed to simplify complex problems with the development, deployment and management of multi-tier enterprise solutions. Historically, J2EE has been an architecture for building server-side deployments in the Java programming language, making it an obvious choice for building XML-based web services. While web services have only recently been made part of the standard platform in J2EE 1.4, web services support is available for most J2EE application server platforms using the standard JAX-RPC API. These vendors also provide tools to simplify the generation of web services, easing the use of web services in place of Enterprise Java Bean (EJB) components. J2EE also supports discovery of web services in UDDI or ebXML repositories with the JAX-R API.
The Need for Web Services Security
While web services provide a platform for developing reusable distributed components, for business applications, it is imperative that this platform allows transactions to be conducted securely. The notion of security encompasses several goals, including:
Confidentiality and integrity of information exchanged
Authentication of users and services
Authorisation to control and protect access to resources
To achieve these goals, web services protocols need to provide mechanisms to authenticate and encrypt data, and different web services infrastructures must interoperate with each other. There are several options available for securing web. We discuss the importance of delegation and end-to-end security, as well as the benefits of providing Single Sign-on for web services.
Protecting Web Services at Message Layer WS-Security
The WS-Security 1.0 Specification by IBM, Microsoft and VeriSign is the main standard addressing web services security. It is concerned about message-level security (securing the SOAP envelope itself) rather than transport-level security (running HTTP over a secure channel, such as TLS/SSL).
The WS-Security specification proposes an architecture for authentication of SOAP envelopes in the form of digital signatures. These digital signatures are usually generated with standard PKI techniques although a Kerberos binding has been proposed. The latter document is still being debated and no widely-deployed applications are able to currently support it.
Protecting Web Services at Transport Layer SSL/TLS
As web services are typically accessed via HTTP, it is also possible to use the standard TLS/SSL protocol to secure communications at the transport layer. It can be argued that this approach fits more naturally with the web services paradigm, which seeks to reuse as much of existing web infrastructure as possible. The basic infrastructure for securing HTTP with TLS/SSL is widely available, making it easy to develop web services that interoperate. TLS/SSL provides authentication of the server via an X.509 certificate, along with confidentiality and integrity protection of the data. It is also possible to provide authentication of the client using certificates, however this is typically not done in practice as it requires an organisation-wide PKI to be available. HTTP provides a number of options for authentication, including plain usernames and passwords typically used in this scenario.
Windows Integrated Authentication
A client authentication option that is available for Microsoft desktop users is to leverage the Windows Integrated Authentication mechanism that allows authentication of users over HTTP using Kerberos. When web server receives a request from a browser or client supporting Windows Integrated Authentication, it can request the browser to authenticate itself with the SPNEGO protocol. This protocol performs a Kerberos authentication via HTTP. It allows the client to pass a delegated credential for a web application to log in to subsequent Kerberised services on the user's behalf without requiring the user to re-enter the password. The SPNEGO protocol can also authenticate the server as well, providing a useful alternative to the PKI-based authentication used by TLS/SSL.
Windows Integrated Authentication provides a useful mechanism for extending a Single Sign-on environment to web applications and web services. It is supported on all Windows desktops later than Windows 2000. This mechanism is supported in Microsoft IIS for authentication to ASP or web pages. It can also be used with J2EE servers and Java clients with Vintela SSO for Java (VSJ).
Controlling Access to Web Services
WS-Security deals with authentication and protection of SOAP messages, but does not address the issue of authorisation to the services themselves. While standards bodies have plans to address these issues, there is no widely-deployed or agreed upon standard which can be used by developers of these applications today. As web services are commonly developed within application server containers like J2EE and ASP.NET, it is possible to provide authorisation for web services using the standard mechanisms available with these platforms. Again, this reinforces the web services idea of reusing infrastructure where possible. Both J2EE and .NET support the idea of "declarative authorisation". Users are authorised by declaring which roles are permitted to access given resources, and specifying users' membership of these roles.
Delegation and End-to-end Security
An additional issue to consider for web services is the notion of end-to-end security. This property means that it is possible for a request made by a client to be authenticated all the way through to its final destination. As SOAP is designed to be a multi-hop protocol, we must consider the issue of ensuring authentication and authorisation at each hop. In addition, it is typical for a web service to require the services of one or more other web services, each of which requires additional authentication. In considering end-to-end security, there are two scenarios to address:
End-to-end message authentication this is where we wish to ensure that the authentication and integrity protection on a SOAP message is retained regardless of the number of hops the message traverses.
End-to-end delegation in this scenario, we wish to authenticate to a given web service and then have that service access other services on our behalf. To do this, we have to delegate a credential to the web service that it can use to authenticate to other services.
In our scenario, delegation is necessary to ensure that credentials used to authenticate users when they log in via their web browsers can also be used to authenticate to one or more web services.
End-to-end Security Using Passwords
If the web service is being authenticated using a plaintext password over HTTP, then it is possible for web service to reuse this password to authenticate to other services. This is a very common scenario, supported by the Java Authentication and Authorisation Service (JAAS) used in J2EE, for example. However, the key disadvantage is that this mechanism prohibits end-to-end message authentication, as any service at any hop could have forged the message. Furthermore, this approach exposes the password to one or more services which can then use this to authenticate to any service on users behalf without constraint. This creates significant doubt about the security of using passwords for delegation.
End-to-end Security Using PKI
Another approach is to use a private key to digitally sign messages using WS-Security. This is advantageous as it provides end-to-end message security with non-repudiation. Thus, only messages originator can sign it. Though it is not possible to delegate private key to other web services to authenticate on user's behalf, it is possible to pass signed "assertions" (like SAML token) which can be used to authenticate a service on user's behalf. While this approach is very secure, it relies on a ubiquitous PKI, private keys and certificates issued to all users. Unfortunately, for many large organisations with an investment in their existing infrastructure, this is not an option. In the delegation case, this also requires all services we wish to authenticate support a common assertion protocol like SAML. Unfortunately, such assumption is largely unmet in the vast majority of corporate networks.
End-to-end Security Using Kerberos
A third option is to use Kerberos to authenticate users, and use the delegation feature of Kerberos to pass a credential to each hop for further authentication. This approach has the advantage that the delegated credentials have a limited lifetime, and can be constrained to a range of addresses so that they cannot be arbitrarily used. Furthermore, when Kerberos is used with Windows 2003, it is feasible to further restrict the services available to an intermediate web service by using the constrained delegation features with Active Directory 2003.
The infrastructure for Kerberos is available to many organisations by default when they use Microsoft Active Directory to authenticate users. It is supported by most other operating system platforms. Kerberos can also be used for end-to-end message security as described in the Web Services Security Kerberos Token Profile (see Links & Literature). However, one disadvantage when compared to PKI is that the message must be authenticated with a different key for each hop that requires authentication. With PKI, it is only necessary that each hop trusts the public key used to verify the signature on each message.
Nevertheless, Kerberos authentication provides an excellent compromise between practicality of a password-based system for delegation, and security of a PKI-based system for end-to-end message integrity.
Single Sign-on (SSO)
A corollary to solving the end-to-end security problem is providing Single Sign-on (SSO) for web services. An SSO solution allows users to authenticate themselves just once to access information on any of several systems. For web services, this is imperative, not only because it greatly decreases the solutions cost of management, and improves the user experience, but also because it provides the ability to make security pervasive throughout the solution. Without SSO, it would be necessary for users to remember different passwords when accessing different services. It would also be near impossible for one web service to authenticate to another without a common view of the identity that they should use.
There are several mechanisms for achieving SSO, including:
Synchronising usernames and passwords across all systems
Mapping between different usernames and passwords with an SSO service
Using a pervasive authentication infrastructure like Kerberos, which is explicitly designed for SSO
These options represent a rough continuum from the least secure option (password synchronisation) to the more secure Kerberos solution. However, it is often the case that security is inversely proportional to usability. Almost every system supports passwords in some form, whereas allowing Kerberos authentication requires specific support from the application. Fortunately, with the increasing deployment of Active Directory, using Kerberos for Single Sign-on is becoming an increasingly viable alternative to the password synchronisation and mapping solutions. Kerberos is supported by a wide range of applications, including SAP, Oracle and DB2. In addition, Kerberos provides other benefits such as secure delegation which are important for web services, hence making it an obvious choice for Single Sign-on.
Summary
While the security infrastructure for web services is immature, it is possible to provide a rich set of security functionality by reusing existing web security mechanisms such as HTTP authentication and SSL/TLS. We have identified several options for security in a web services scenario. These options have various advantages and disadvantages, depending on the particular use case situation. The challenge is to select from these alternatives a set of mechanisms that maximises security while providing rich functionality such as SSO and delegation.
The Solution Using Windows Integrated Authentication for Web Services SSO
In selecting an option for providing security and SSO, we should consider a pragmatic objective. The web services paradigm of reusing infrastructure, wherever possible, should be reinforced, by seeking a security solution that fits most naturally with our existing environment.
If your users are using Windows desktops and authenticating to Active Directory, then using a Kerberos solution based around the Windows Integrated Authentication mechanism is an obvious choice. It provides a SSO environment that requires users to enter their passwords only once at desktop login. Furthermore, it also provides an authentication and delegation mechanism which is both secure and flexible. In addition, by using Active Directory, it is also possible to have a common authorisation environment using Active Directory groups, as well as supporting scalable and flexible authentication across multiple security domains by using the cross-realm and cross-forest trust features of Kerberos. Lastly, using Windows Integrated Authentication can be supported using .NET web service clients and servers natively, and with J2EE by using Vintela SSO for Java (VSJ) for web services extensions without changing any code, or adding any new infrastructure elements.
In the following section, we show how these services can be configured with standard web services technology to provide SSO for web services for both J2EE and .NET applications.
Deploying SSO for Web Services
At the start of this article, we outlined a situation in which an organisation needs to integrate a mish-mash of heterogeneous systems to provide a rich application environment. In the subsequent sections, we will demonstrate how this can be done securely with SSO environment without altering the infrastructure, or rewriting any core services.
Coping with Company Mergers Using Cross-Forest Authentication
One of the first problems the hypothetical developers face in our scenario is coping with different authentication environments in Xerxes Mutual and Short-Term Capital Management. While both are running Active Directory on Windows 2003 server, identity information is stored in separate Active Directory forests. Furthermore, there is no mechanism currently for users in Xerxes Mutual to be authenticated to services in Short-Term Capital Management and vice versa.
Fortunately, since they are both using Windows 2003, cross-forest trust can be enabled to provide this functionality. This is a simple one-time activity that creates a means for users to be authenticated in either the parent organisation or subsidiary. This requires no change to any client or desktop systems.
Authenticating to the Web Tier
The first step in achieving SSO is to enable Windows Integrated Authentication to the web tier. This enables users to transparently authenticate to web applications and provides for delegation of credentials. To do this, it is simply a matter of having the users log on to a Windows 2000 or better domain controller, and configure their Internet Explorer browser to enable Windows Integrated Authentication for intranet servers. No additional software or configuration is required on the client side. This allows users to authenticate once at login time, and subsequently to authenticate to any web applications without having to represent their passwords. This setup applies to both the Retail Brokering and Commodity Trading applications.
Additionally, by using Windows Integrated Authentication in this way, we can also support authentication of users via a removable smart card, VPN, or over a dial-up connection all without any modifications to the backend systems.
It should be noted that while we have chosen to use web clients for both applications in our scenario, the same approach would work for .NET or Java clients.
Web Services SSO with .NET
The Retail Brokering application resides on an ASP.NET server. To provide SSO, we are required to enable Windows Integrated Authentication for the server. We also need to allow delegation of the Kerberos credential so that they can be used to access the cash management and commodity trading services.
ASP.NET provides a "declarative delegation" strategy for passing credentials to web service client calls. This involves adding the following entry to web application's Web.config file to enable "impersonation" (a pre-requisite for credential delegation):
Furthermore, the web application code itself must flow the original caller's security context to the embedded web service call by setting the credentials of the client proxy (see below). This simple adjustment is all that is required to support transparent SSO.
In our example, the Retail Brokering application interacts with the Cash Management application to add and remove funds as units are bought and sold. The Cash Management service exposes the following method as a web service:
[WebMethod] public bool UpdateAccount(int amount, string accountName);
The Retail Brokering application in our scenario uses a .NET client embedded in a web application, which might utilise this service by implementing the following AccountHandler class:
[System.Web.Services.Protocols.SoapRpcMethodAttribute("", RequestNamespace="http://cashfund.foo.com/wsdl/Update", ResponseNamespace="http://cashfund.foo.com/wsdl/Update")] [return: System.Xml.Serialisation.SoapElementAttribute ("result")] public bool UpdateAccountDetails(int amount, string accountName) { object[] results = this.Invoke("UpdateAccount", new object[] {amount, accountName }); return ((bool)results[0]); } // John Smith has just bought worth of soybeans // using his account at the Cash Management Fund. This amount // must be debited from his account. public static void Main(string[] args) { string name = "John Smith"; int amount = -1000; AccountHandler accHandler = new AccountHandler(); accHandler.Credentials = System.Net.CredentialCache.DefaultCredentials; if (!accHandler.UpdateAccountDetails(amount, name)) { Console.WriteLine("Failed to " + (amount > 0 ? "credit" : "debit") + " {0} to account {1}", amount, name); } }
Here, the caller's credentials are explicitly set using a C# Property in the System.Web.Services.Protocols.WebClientProtocol class. By enabling "declarative delegation", the web service call will use the delegated credential, rather than ASP.NET server's credentials.
With this setup enabled, the Retail Brokering application can now access the Cash Management system, and authenticate using the user's delegated credential. Since we have created a cross-forest trust between Xerxes Mutual and Short-Term Capital, the Cash Management system will be able to authenticate any user in Xerxes Mutual.
Web Services SSO for J2EE
Vintela SSO for Java (VSJ) web services extensions provide plug-ins to implement the Windows Integrated Authentication mechanism for web services. When used with VSJ, these extensions allow Windows Integrated Authentication to be enabled without modifying the underlying source code through a "declarative delegation" mechanism similar to that provided by ASP.NET. In our scenario, users will be accessing the Commodity Trading J2EE application via Internet Explorer. VSJ will be configured with the web services extensions to provide servlet filters that allow J2EE to support authentication via the SPNEGO protocol and let these credentials to be transparently delegated when making subsequent calls to other services via HTTP. These filters take a number of initialisation parameters, expressing various ways to set up the security context between the HTTP client and target server. The relevant part of the deployment descriptor might look as follows:
authFilter com.wedgetail.idm.sso.AuthFilter Filter to enable Windows Integrated Authentication idm.realm COMMODITIES.XML.COM delegFilter com.wedgetail.idm.sso.exp.DelegAdminFilter Filter to enable transparent delegation of Kerberos credentials obtained during Windows Integrated Authentication. idm.sso.exp.delegate true idm.sso.exp.mutualauth true
The authFilter enables user to be authenticated via Windows Integrated Authentication, and is supplied as part of VSJ. The delegFilter (part of web services extensions) enables the credential delegated as part of this authentication to be used transparently when authenticating to subsequent services. This provides the "declarative delegation" functionality similar to that used by the ASP.NET application.
In our example, the Commodity Trading application needs to determine the cost of borrowing a certain amount of money in a particular currency for a specified period of time. The Cash Management Fund application is a .NET web service which exposes the following C# method:
[WebMethod] public int GetBorrowingCost(int amount, string currency, int period);
The Commodity Trading application needs to gain access to short-term credit in order to conduct a trade. It acts as a web service client to the Cash Management Fund, requesting the cost of a credit line. A typical web service call (using a DII or Dynamic Invocation Interface client) might be:
String endPoint = http://cashfund.short-term- cm.com:7001/services/CreditService""; String serviceName = "CreditService"; String servicePort = "CreditServicePort"; String ENCODING_STYLE_PROPERTY = "javax.xml.rpc.encodingstyle.namespace.uri"; String URI_ENCODING = "http://schemas.xmlsoap.org/soap/encoding/"; ServiceFactory fact = ServiceFactory.newInstance(); Service serv = fact.createService(new QName(serviceName)); Call call = serv.createCall(new QName(servicePort)); call.setTargetEndpointAddress(endPoint); call.addParameter("Amount", XMLType.XSD_STRING, ParameterMode.IN); call.addParameter("Currency", XMLType.XSD_STRING, ParameterMode.IN); call.addParameter("Period", XMLType.XSD_STRING, ParameterMode.IN); call.setReturnType(XMLType.XSD_STRING); call.setOperationName(new QName("getBorrowingCost")); call.setProperty(ENCODING_STYLE_PROPERTY, URI_ENCODING); // We want to borrow 1000 for 90 days // Object[] inParams = {Integer.valueOf(1000), "USD", Integer.valueOf(90)}; Integer cost = (Integer) call.invoke(inParams);
This demonstrates the JAX-RPC interface is used to construct a SOAP message to dynamically access a given web service. The invoke method above will then use the standard URLConnection interface to send this message over HTTP. The code for the latter step might look like:
URL url = new URL(endPoint); // Open an InputStream to the requested resource and // start reading from the stream URLConnection connection = url.openConnection(); InputStream in = connection.getInputStream(); ...
With the delegFilter filter enabled, the URLConnection returned from the call to URL.openConnection() transparently adds Windows Integrated Authentication support to the HTTP request using the configuration properties specified in the above deployment descriptor (for example, whether the client should use delegated credentials, if available, whether to request authentication by the server, etc). This approach also works well when using a tool that generates client stubs using HTTP. In either case, there is no need to change any web service client code.
Enabling Windows Integrated Authentication for Commodity Trading Web Service
Now, we only need to add Windows Integrated Authentication support to the remaining Commodity Trading application web service and our scenario is complete. On the server side, in J2EE, web services are typically implemented behind a servlet. Most J2EE application servers have web service functionality built-in, and for an open source servlet container such as Tomcat, a library like Apache Axis can be plugged in to provide such functionality. The J2EE container can provide authentication/authorisation at the servlet level utilising VSJ. This is achieved by adding a filter similar to the authFilter above before the servlet that implements the web service. For example:
authFilter com.wedgetail.idm.sso.AuthFilter Filter to enable Windows Integrated Authentication idm.realm COMMODITIES.XML.COM
Authorisation: Final Piece of Puzzle
So far, we have managed to enable authentication and SSO to all components in our scenario. We have also enabled transparent delegation to each web service. The only remaining task is to set authorisation privileges for accessing each service.
As mentioned earlier, the easiest way to do this is to use available mechanisms in the application servers to specify authorisation rules. Fortunately, by using ASP.NET and VSJ, we can manage these permissions centrally by assigning users to one or more Active Directory groups. This allows us to provide a central point of management for authorisation a goal equal, if not greater, in importance to ensuring a single point of managing identity.
Creating Groups in Active Directory
To create groups, we can use the Active Directory User and Group Management MMC snap-in. We will create two groups:
Retail brokers users with permission to access the Retail Brokering application
Commodity traders users with permission to access the Commodity Trading application
Configuring Authorisation Permissions with ASP.NET
To allow access to the Retail Brokering application, we add the following entry to the application Web.config file:
This entry ensures that only members of the "Retail Brokers" group will have access to the application.
Configuring Authorisation Permissions with Vintela SSO for Java (VSJ)
Vintela SSO for Java (VSJ) provides a similar declarative delegation mechanism that allows authorisation of users using Active Directory groups. For this, we need to create a separate XML file containing security constraints with the usual J2EE declarative authorisation syntax:
Commodity Trading App /trading/* Commodity Traders
Then, add the following initialisation parameters to the authFilter configuration:
idm.access.policy policy.xml idm.access.groupsAsRoles true
The application will now require the user to be a member of the "Commodity Traders" group to access the application.
Conclusion
Web services provide a powerful paradigm for developing a new class of applications that integrate a range of services to deliver rich and valuable applications. A key success of this paradigm is the focus on reusing existing web infrastructure to promote a high level of interoperability and reuse amongst components.
By adopting the same approach, to achieve security and SSO, we can also reap the benefits of our existing infrastructure. In this article, we have shown that regardless of whether you are developing applications in J2EE on UNIX servers or Microsoft .NET, it is possible to support a rich set of security functionality by reusing your existing infrastructure. In demonstrating this, we have outlined a realistic scenario that shows how this can be done by simply modifying the way applications are deployed rather than changing existing code.
Glen Lewis was recently promoted from team lead on Vintela's VMX product to vice president of engineering to draw upon his wealth of development, organisational, and management experience. Glen draws upon over 20 years of extensive and diverse development experience, covering a wide range of business applications.
Links & Literature
ASP.NET http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnnetsec/html/ SecNetch08.asp
AXIS http://ws.apache.org/axis
Introduction to Kerberos http://www.wedgetail.com/technology/kerberos
.NET Framework Developer's Guide How ASP.NET Security Works http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/ cpconhowaspnetsecurityworks.asp
OASIS http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
SOAP http://www.w3.org/TR/2000/NOTE-SAP-20000508/
SPNEGO http://www.ietf.org/internet-drafts/draft-brezak-spnego-http-04.txt
Web Services Primer http://www.wedgetail.com/technology/web_services.html
Web Services Single Sign-on http://www.vintela.com/products/vsj/
WS Security Kerberos Token Profile http://www.oasis-open.org/committees/download.php/1049/WSS-Kerberos-03.pdf
WS Security X509 Profile http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
WS-Security http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp
XMLDSig http://www.w3.org/Signature/
|
