CSG, Dartmouth, September 2003 Web Services and Security: all the rope you'll ever need RL “Bob” Morgan University of Washington CSG Dartmouth September

CSG, Dartmouth, September 2003

Web Services and Security:all the rope you'll ever need

RL “Bob” MorganUniversity of Washington

CSGDartmouth

September 25, 2003


Topics

● Web Services goals and roadmaps● Players● Security-related specifications● Relationship to other specs (eg SAML)


Web Services modest goals

● As “the web” revolutionized and unified ...– information publishing and distribution– user access to applications

● So could basing all communication on web-based standards revolutionize and unify ...– distributed computing and protocols– application service interfaces– how systems are designed and composed– ... and this time we mean it


Web Services replaces ...

● all those funky app-defined interfaces– dozens of them across all our app systems– and good riddance

● even more standardized interfaces– eg database, especially stored procedures

● and all those “standard” protocols– eg POP/IMAP/CAP, also DCOM/CORBA/DCE/RMI

● all your infrastructure (are belong to us ...)– Kerberos, LDAP, CAs, etc


Whose vision is this?

● started with programmers seeking easy RPC– XML-RPC (1998), XML 1.0 with simple types

● (and XML-RPC remains simple, and useful, to some)

● Microsoft is now leading the parade, mostly– IBM is prime co-conspirator– Sun, Oracle, other tech providers contribute– all apps vendors re-tool– many open-source tools

● Apache Axis, Perl/Python/etc support, ...


WS and standards bodies

● W3C– XML, XML Schema, WSDL, SOAP 1.2, XML-

Dsig– WS Architecture activity

● OASIS– explosion of stuff on top of XML/WS– SAML, WS-Sec, UDDI, XACML, XrML, ...

● IETF: app protocols a thing of the past ...● WS-I.org

– “interop profiles”, not standards per se


SOAP protocol architecture

● XML and namespaces, “extensibility model”

● header + body structure● processing features get added to headers● while body contains “app data”● familiar email/web model

● SOAP-defined addressing and routing● endpoints are URIs independent of networks

so works thru firewall/NAT/phones/email● binding to HTTP(s), SMTP, what-have-you● explicit support for intermediary nodes


WS-Sec principles

● MS/IBM “roadmap”, April 2002● new version (apparently) this month

● composability● each spec defines specific service● base is simple unidirectional SOAP message● message protection, reliable transfer, transaction

secure session, sign-on, federation, etc; can be added to header independently

● generalizing existing services/structures● tickets/certs/attributes are “claims”● issuers are “security token services”


WS-Sec (and related) specs

● WS-Security “core” message protection– now committee spec from OASIS TC– apply XML-Signature to SOAP msg protection– formats for security tokens in messages

● X.509, Kerberos, SAML, user/password, extensible– but what to do with them is left to other

specs ...● All other specs published by MS/IBM/etc

– “may change, cautioned against relying”– “no rights to patents implied”


WS-Policy, Trust

● WS-Policy adds policy expressions to WSDL– interface can express capabilities,

requirements– policy definitions left to other specs– WS-SecurityPolicy defines policies for WS-Sec

● require integrity/confidentiality/token/etc

● WS-Trust– request/response for security tokens

● ala KDC, X.509 CA, user/passwd authentication


More WSS

● WS-SecureConversation– security context establishment, key

agreement● ala GSSAPI, SSL

● WS-Federation– account linking, pseudonyms, SSO– passive, aka browser profile

● duplicates function of SAML browser profile– active profile, ie SOAP-savvy client


related WS-* specs

● WS-ReliableMessaging– TCP-style sequence numbers, retransmission

● transactions– WS-Coordination– WS-AtomicTransaction– WS-BusinessActivity

● biz process composition● messaging/events


non-WS XML sec specs

● there's more to WS than just XML ...● SAML/Shibboleth

– Shib supports browsers, not WS per se● attribute req/resp is SOAP, could define WSDL ...

– SAML is one token type for WS-Sec, WS-Fed● Liberty

– defining higher-level services– profiles of WS-Sec, SAML for


So ... will this work?

● XML is infinitely extensible, dynamic● for security you want provable specs

– so fundamentally at odds– limited subset of XML for this purpose?

● all-XML-all-the-time blurs protocol layers● same parser parsing all of them?● is it a protocol error or a data error?● but at least it's not ASN.1 ...

● but maybe it will just have to ...

Documents

CSG, Dartmouth, September 2003 Web Services and Security: all the rope you'll ever need RL “Bob” Morgan University of Washington CSG Dartmouth September