Identity, Security, and XML Web Services Jorgen Thelin, Cape Clear Software SAML / ws-security orientation Definition of identity: (dictionary def'n) WHo a person is, or the qualities of the person/group 3 main concepts: 1) who you are 2) how do you prove who you are 3) what can they be allowed to do? 1) Who are you (who, who, who, who) Identity equates to a particular subject or principle Usually equates to a person but could be a group or corporation or even s/w (why not a device or location?) 2) Proof Usually thru official dox - license, passport, etc. In computing terms - username + password, X.509 digi-certs Credentials let you move thru phases of authentication/authorization 3) Permissions Allows us to do stuff! Showing how UK passport gets you access to UK services since you're a citizen If you lose passport, you're still a citizen, but burden of proof is hard (harping on passports -- who carries their passport everywhere?) Need different permissions to use/utilize different services (just cuz you can drive a car doesn't mean you can drive a big truck) Permissions and entitlements for an identity is determined by credentials Permissions and credentials are used for policy enforcement (note this all pretty basic security/auth'ing framework) How does this affect Web Services? Security and identity are fundamental to deploying Web Services (presumably inter-enterprise, not intra-) Security policy decisions are based on caller's identity Authentication - who's the caller? How did they prove their credentials Trust relationship needs to be tight Once we get authentication -> authorization Delegation and proxies are still another dimension (we won't talk about it here though :() Attributes - more about the caller (metadata): e-mail, dept #, etc. Could be used to customize data returned to caller (ya know, personalization) Slide of end-to-end architecture from client to an EJB (pick up the slides) Architecture has various gateways to ensure security (but there are problems) We really want to get identity info and credentials from end-to-end Get it from client on outside to Web Services broker on the inside Cache it for better performance Confusion over orientation of slide gfx...more info to answer crowd questions in following slides What happends when back-end brokers talk to multiple things: CORBA, EJB, Web Service How do credentials survive the whole transaction? "Last mile problem" Enabled by standards and adherence to them What do we need for credential interop? 1) Standard ways to represent credential data XML - SAML 2) Standards way to obtain credentials Single-sign on (ugh) 3) Way to transport credential data Put 'em in a SOAP header, ala WS-Security Need to worry about not doing the right thing to process credentials...uh...? Concepts can be applied to anything XML-based Could make RDF of identity -- but how to prove this? Talking about WS-Security Started by M$FT, handed over to OASIS WS-Security spec defines tokens (signed and unsigned) Unsigned = username + pass Signed = digi-cert XML = SAML, usually self-verified/signed Oy...complex XML security dialogue graphic Presenter is just reading the process on the slide SAML - XML spec for exchanging security information Defines how to represent credentials and protocol for querying SAML services Doesn't define how to obtain credentials Assertions in SAML: 1) Authentication 2) Attribute 3) Authorizations (Read the spec for more info...OK?) Yipes...an eyechart full of XML showing how username token is embedded in XML Presenter is walking thru the WS-Security XML schema elements Now we show embedding a binary X.509 digi-cert into the XML Leaving...bored to death! --- metadata --- Append email address for mail bounceback below cgervais@mac.com, etcon@crystalflame.net, URLS cited http://www.capeclear.com http://www.capescience.com http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss