Greg Giles, Cisco Systems. Is compression a valid candidate for a standard?

Transcription

1 1 WebServices Framework & Assertion exchange using SAML Submitted By : Abstract: Krishna Sankar, Cisco Systems Greg Giles, Cisco Systems This paper defines a general framework for web services and attempts to point out some of the facilities needed. It dives a little deeper into two areas first the intra web services communication and second exchange of assertions between web services using the SAML standard being developed under OASIS. Some of the question to think about : Do we need a lightweight XML infrastructure for the intra web services communication Will it provide interoperability between different implementations (eg. CORBA,COM,RMI et al) Do we need to standardize context What about session management Is compression a valid candidate for a standard Where can we leverage the SAML initiative, which provi des the framework for exchanging assertions Introduction The term Web Services has an XML over http look and feel. However, it need not be so. We can look at a web service as a bundle of active functionality. We could create applications by syndicating web services, which is a better model than the current monolithic applications. A web service is a thing that responds to messages and that is one of the main difference from a web service and an object, for example. The core of a web service is the business logic. The core would be supported by other related capabilities like logging, error handling et al by a web service container. Figure 1 outlines this concept.

2 Web Services Framework Messaging Middleware Messaging Framework To Software/Data Bus Security (SAML,XKMS) Profiles Web Service Logic XML Interface (XMLP) Database Session Manager XML Compression Context Logging Admin Error Handling Perf. Counters Intra Web Services bus Web Services Container Figure Anatomy of a Web Services Framework With reference to Figure 1, for current discussion we can ignore database interface, logging, admin, error handling and the performance interfaces. These would be provided by the operating and developing environments like Windows, Java et al. Even though it is desirable to have standards in these areas, I think we can live with out standards, but depend on programming models provided by implementations and 3 rd party vendors. We would need standards in the more communication/protocol-oriented interfaces. 2

3 XML Interface: This is the main interface for a web service. This interface communicates with the outside world thru an XML technology most probably XMLP with binding to protocols, most common being http. The XMLP standard we are working on should suffice this interface. 2. Compression: This is more towards performance. Compressing the messages, especially XML data can dramatically improve throughput and optimize network traffic. There is an opportunity here for a wrapper standard for compression. This is important especially when the messages cross many organizational and system boundaries. 3. Session Manager: Currently the web service assumes a stateless machine with sync or async communication. The state could be maintained as a part of some piece of information at the payload level (E.g. A Purchase Order Number) or there could be specific mechanisms like authtoken for UDDI or session tokens. There is an opportunity here to standardize the way session and session information is handled. The SAML (which will be covered later) could be leveraged to exchange session information 4. Context: Context is related to session, but could also carry geographical information, run time information, load balancing information et al. Again, there is an opportunity to standardize the context management, information hierarchy et al. 5. Profiles: A profile is related to session as well as security. It can also contain authorization information (for systems and human personnel) As web services are active elements, they should have the notion of right and wrong! 6. Security: Security is a broad area and we could define the minimum security implications for a web service at various layers. This note could be more descriptive rather than prescriptive. We do have an opportunity here to provide some leadership. 7. Intra web services communication: The main (or the only) communication pipe a web service has is the XML interface. For a normal standalone Internet based web service, this is sufficient. Nevertheless, if we cross to the world of syndicated services or service aggregations we would quickly see the need for a lightweight protocol. Figure 2 shows the concept of the syndicated services. 3

4 83 84 Figure The syndicated service talks to the outside world using the XMLP bus. However, internally, the service itself consists of three web services (green, red and gray), with two instances of one of them (the green one) Moreover, the red one does not have an XML bus. Usually the plan would be to use some proprietary forms of intra web services bus (RMI, COM,..) but that would take the interoperability out of the web services at this layer. There is an opportunity here to propose an on the wire lightweight protocol, syntax and semantics. Innovations like e-speak, Jini, fipa et al have many good ideas, but all are fragmented. 4

5 Do we dare go there Don t know ;-) We plan to evangelize a MOM based middleware, possibly some XML compression and some form of publish/subscribe mechanisms because of the lack of some standards. SAML for exchanging assertions between web services: What is SAML SAML stands for Security Assertions Mark-up Language. The charter of the group is to define a data format for authentication and authorization assertions, including descriptions of authentication events. The authorization includes group and role membership, profile information et al. One feature of SAML which could be very valuable for web services is the fact that SAML will allow assertions to be made about anonymous principals, where "anonymous" means that an assertion about a principal does not include an attribute uniquely identifying the principal (ex: user name, distinguished name, etc.). The SAML messaging protocol allows push and pull model. It also has the notion of security zones, which is good for the syndicated/aggregated services. We could have one zone for syndication and another for external interaction thru the XML bus. SAML will define bindings for browser, HTTP, MIME, XMLP and ebxml. Where does it stand now How can it be leveraged for web services The obvious place to start with, is the exchange of security assertions between web services be at the external XML communication or the intra web services bus. I think, when we build applications, based on web services, the SAML should be employed in the exchange of more information like the session, context, profiles et al. Currently the SAML group is concentrating only on exchanging authentication and authorization information. Once the group delivers on these, it would be an easier task to extend the SAML standard to include session, context and profile information. Sample SAML use cases and XML documents: <TBD : 2 diagrams, couple of use cases and 2 or 3 XML sample docs> Conclusion: This paper covers only a very small set of the web services world. There are many other related topics like negotiations, discovery, dynamic configuration using TPAs, collaboration protocols, redundancy/failover et al. The questions raised are : 5

6 Do we need a lightweight XML infrastructure for the intra web services communication Will it provide interoperability between different implementations (eg. CORBA,COM,RMI et al) 2. Do we need to standardize context 3. What about session management 4. Is compression a valid candidate for a standard 5. Where can we leverage the SAML initiative, which provides the framework for exchanging assertions 6