1. A PPARC funded project Single Sign-On Proposal Guy Rixon IVOA Interoperability Meeting Cambridge MA, May 2004

2. 2 > Goals Software-to-software authentication Protect services from misuse User signs on once per interactive session Minimal impact on service providers No shared DBs of passwords Dont register each user at each service Minimal impact on users Register once for entire VObs, on-line One password for entire VObs. No p(r)oxy certificates for user to manage

3. 3 > Parts of proposal Proposal text on IVOA wiki http://www.ivoa.net/twiki/bin/view/IVOA/SingleSignOnProposal Proposal in two parts: 1. Message-level protocol for authentication 2. How client s/w gets its credentials 2 nd expands on 1 st part More architectural More sociological Could adopt 1 st part but not 2 nd part

4. 4 > Message-level protocol (1) Digitally sign body of message Prevents alteration of message Dig-sig mark-up goes in SOAP header Use WS-Security encoding Put X.509 ID certificate in message Certificate contains public key + user ID Put certificate in SOAP header WS-Security encoding again Certificate + signature = authentication Signature on msg ties msg to key pair Certificate ties key pair to account ID

5. 5 > Message-level protocol (2) Basic signed message is vulnerable to replay attack Use nonce and timestamp to defeat this Nonce = unique message-ID Timestamp = time of message creation Service uses nonce & timestamp to detect bad messages Rejects messages older than (say) 5 minutes Records nonces from msgs in last 5 minutes Rejects messages with duplicate nonces Nonce + timestamp travel in SOAP header WS-Security encoding again Sender signs them to avoid tampering

6. 6 > Example SOAP header <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext- 1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity- utility-1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">... ivo://ast.cam.ac.uk/Community/GuyRixon 4cz8rnEhdsjmcie2138ck== 2004-05-12T14:26:00+01:00

7. 7 > SOAP-header example (cont.)......

8. 8 > Certifcate authority (1) All X.509 certs come from a certificate authority (CA) Signs cert. Establishes link between public key and user ID There are external Cas E.g. UK e-Science CA E.g. Verisign Service provider trusts authentication process only if he/she trust the CA

9. 9 > Certificate authority (2) There are problems with CAs in the IVO High-security CAs demand off-line registration Not all astronomers have access to recognized CAs Set of all relevant CAs is open… …but CA details need to be preloaded in each service How to trust CAs? However, can run own CA locally Commonly done in early grid projects Toolkits exist

10. 10 > Proposal VObs community services: Registration point for users Represent real-world communities Allows user sign-on to VObs with password Issues X.509 certs in exchange for password Also handles authorization E.g. service provider authorizes whole community E.g. service provider authorized group within community

11. 11 > How the credentials are passed User Portal/ Desktop app. Portal/ Desktop app. Community service Community service Service Sign in with password Issue X.509 cert. Send signed message