WebServices Framework & Assertion exchange using SAML
1Submitted By : Krishna Sankar, Cisco Systems
2
Greg Giles, Cisco Systems
3 4
Abstract:
56
This paper defines a general framework for web services and attempts to point out some of the
7
facilities needed. It dives a little deeper into two areas – first the intra web services
8
communication and second exchange of assertions between web services using the SAML
9
standard being developed under OASIS.
10 11 12
Some of the question to think about :
13 14
• Do we need a lightweight XML infrastructure for the intra web services communication
15
? Will it provide interoperability between different implementations (eg.
16
CORBA,COM,RMI et al)
17 18
• Do we need to standardize context ?
19 20
• What about session management ?
21 22
• Is compression a valid candidate for a standard?
23 24
• Where can we leverage the SAML initiative, which provi des the framework for
25 exchanging assertions ? 26 27 28 Introduction 29
The term “Web Services” has an XML over http “look and feel”. However, it need not be so.
30
We can look at a web service as a bundle of active functionality. We could create applications by
31
syndicating web services, which is a better model than the current monolithic applications.
32
A web service is a thing that responds to messages and that is one of the main difference from
33
a web service and an object, for example. The core of a web service is the business logic. The core
34
would be supported by other related capabilities like logging, error handling et al by a web service
35
container. Figure 1 outlines this concept.
36 37
Web Service Logic Security (SAML,XKMS) Profiles X M L I n t e r f a c e (XMLP) Database S e s s i o n M a n a g e r L o g g i n g Admin E r r o r Handling Perf. Counters X M L Compression
Web Services Container
Intra Web Services bus
?
C o n t e x t?
?
?
?
Messaging Framework To Software/Data BusWeb Services
Framework
Messaging Middleware 38 • Figure 1 39 40Anatomy of a Web Services Framework
41
With reference to Figure 1, for current discussion we can ignore database interface, logging,
42
admin, error handling and the performance interfaces. These would be provided by the operating and
43
developing environments like Windows, Java et al. Even though it is desirable to have standards in
44
these areas, I think we can live with out standards, but depend on programming models provided by
45
implementations and 3rd party vendors.
1. XML Interface: 48
This is the main interface for a web service. This interface communicates with the
49
outside world thru an XML technology – most probably XMLP with binding to protocols, most
50
common being http. The XMLP standard we are working on should suffice this interface.
51
2. Compression: 52
This is more towards performance. Compressing the messages, especially XML data
53
can dramatically improve throughput and optimize network traffic. There is an opportunity here
54
for a wrapper standard for compression. This is important especially when the messages cross
55
many organizational and system boundaries.
56
3. Session Manager: 57
Currently the web service assumes a stateless machine with sync or async communication.
58
The state could be maintained as a part of some piece of information at the payload level (E.g.
59
A Purchase Order Number) or there could be specific mechanisms like authToken for UDDI or
60
session tokens.
61
There is an opportunity here to standardize the way session and session information is
62
handled. The SAML (which will be covered later) could be leveraged to exchange session
63
information
64
4. Context: 65
Context is related to session, but could also carry geographical information, run time
66
information, load balancing information et al.
67
Again, there is an opportunity to standardize the context management, information hierarchy et
68
al.
69
5. Profiles: 70
A profile is related to session as well as security. It can also contain authorization information
71
(for systems and human personnel) As web services are active elements, they should have
72
the notion of right and wrong !
73
6. Security: 74
Security is a broad area and we could define the minimum security implications for a web
75
service at various layers. This note could be more descriptive rather than prescriptive. We do
76
have an opportunity here to provide some leadership.
77
7. Intra web services communication: 78
The main (or the only) communication “pipe” a web service has is the XML interface. For a
79
normal standalone Internet based web service, this is sufficient. Nevertheless, if we cross to
80
the world of syndicated services or service aggregations we would quickly see the need for a
81
lightweight protocol. Figure 2 shows the concept of the syndicated services.
83
• Figure 2 84
85
The syndicated service “talks” to the outside world using the XMLP bus. However,
86
internally, the service itself consists of three web services (green, red and gray), with two
87
instances of one of them (the green one) Moreover, the red one does not have an XML
88
bus. Usually the plan would be to use some proprietary forms of intra web services bus
89
(RMI, COM, ..) but that would take the interoperability out of the web services at this layer.
Do we dare go there ? Don’t know ;-) We plan to evangelize a MOM based middleware,
94
possibly some XML compression and some form of publish/subscribe mechanisms
95
because of the lack of some standards.
96
SAML for exchanging assertions between web services:
97
What is SAML ? 98
SAML stands for Security Assertions Mark-up Language. The charter of the group is to define
99
a data format for authentication and authorization assertions, including descriptions of
100
authentication events. The authorization includes group and role membership, profile
101
information et al.
102
One feature of SAML which could be very valuable for web services is the fact that SAML will
103
allow assertions to be made about anonymous principals, where "anonymous" means that an
104
assertion about a principal does not include an attribute uniquely identifying the principal (ex:
105
user name, distinguished name, etc.).
106
The SAML messaging protocol allows push and pull model. It also has the notion of security
107
zones, which is good for the syndicated/aggregated services. We could have one zone for
108
syndication and another for external interaction thru the XML bus.
109
SAML will define bindings for browser, HTTP, MIME, XMLP and ebXML.
110
Where does it stand now ? 111
112
How can it be leveraged for web services ? 113
The obvious place to start with, is the exchange of security assertions between web
114
services be at the external XML communication or the intra web services bus. I think, when we
115
build applications, based on web services, the SAML should be employed in the exchange of
116
more information like the session, context, profiles et al.
117
Currently the SAML group is concentrating only on exchanging authentication and
118
authorization information. Once the group delivers on these, it would be an easier task to
119
extend the SAML standard to include session, context and profile information.
120
Sample SAML use cases and XML documents: 121
<TBD : 2 diagrams, couple of use cases and 2 or 3 XML sample docs>
122
Conclusion:
123
This paper covers only a very small set of the web services world. There are many other
124
related topics like negotiations, discovery, dynamic configuration using TPAs, collaboration protocols,
125
redundancy/failover et al.
126
The questions raised are :
1. Do we need a lightweight XML infrastructure for the intra web services communication ?
128
Will it provide interoperability between different implementations (eg. CORBA,COM,RMI et
129
al)
130 131
2. Do we need to standardize context ?
132 133
3. What about session management ?
134 135
4. Is compression a valid candidate for a standard?
136 137
5. Where can we leverage the SAML initiative, which provides the framework for exchanging
138
assertions ?
139 140
