The WSTIERIA Project – A Web of Services


Published on

Presentation given by Fiona Culloch at FAM10 on 6 October 2010

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The WSTIERIA Project – A Web of Services

  1. 1. The WSTIERIA Project – A Web of Services 6 October 2010 Fiona Culloch
  2. 2. Project context • Previous EDINA (geo) web services authentication work (SEE-GEO project) • EDINA Digimap uses web services in back end • Delegated authentication work by Shibboleth core team and U. Chicago • JISC Access and Identity Management (AIM) Programme, “n-tier” call
  3. 3. The requirement • Browser-based federated SSO protocols require: – HTTP redirection – Cookies – SSL/TLS – User input (usernames, passwords, etc.) – HTML processing
  4. 4. The problem • Web service clients may support none of these requirements. Consider: – Floating, “back end” client process – Without direct access to user input – Supporting only HTTP, not HTTPS – Or closed-source desktop app with no cookie or redirect support
  5. 5. The consequence • Web services generally do not support federated authentication – Talking about plain HTTP web services – SOAP-based services do have mechanisms • WS-Federation, WS-Trust,… • But complex standards, dependent on framework implementations • Implementations have inter-op issues
  6. 6. First approach: “façade” concept • Separate: – Client data flow (XML over HTTP) – From browser auth flow (HTML, SAML over HTTP) • In the client flow: – URI must contain a valid token – Token obtained from browser auth flow
  7. 7. “Façade” is an authenticating proxy WS Façade Client http://proxy/...438657...XML XML
  8. 8. Façade has two faces WS Façade Client http://url1/...438657...XML XML BrowserSAML HTM L SP http://url2/...438657...
  9. 9. In practice • First step: browser login to façade SP – Standard Shibboleth IdP/SP flow – Façade authorizes (here using ePSA) – If successful, URL with token generated
  10. 10. Copy access link • Paste URL into client application
  11. 11. Unmodified client accesses WS • Via façade, using URL with token – Not via Shibboleth
  12. 12. Implementation methods • In previous work, façade was: – Java servlet – Bespoke SAML SP implementation • Shared tokens with servlet via in-memory DB • WSTIERIA: – Saw similarity to standard HTTP proxy – Investigated off-the-shelf solutions – Pursued Apache + mod_rewrite
  13. 13. Use Apache as façade • Does URL contain /session/nnn/xxx ? – No: reject (Forbidden) – Yes: replace by /ws/xxx • RewriteMap M txt:file RewriteRule ^/session/(.*) ${M:$1|/forbid} RewriteRule ^/forbid – [F] RewriteRule ^/ws(.*) http://wsv/path$1 [P] • File maps valid tokens to “/wms”: • 123456 /ws • 789012 /ws etc.
  14. 14. Problem with façade concept • What if a web service response contains URLs of WS endpoints? – Client may try to access those URLs – But blocked by firewall – Can only be accessed via the façade • Façade must rewrite response data, … http://ws… => …http://façade…
  15. 15. Rewriter implementation • Problem not theoretical: affects Web Map Service example above (GetCapabilities) • Original servlet did Java string processing • Apache can do it by filtering proxied response through a perl script (SetOutputFilter). Details at: –
  16. 16. Problem more general than thought • Thought GetCapabilities was odd accident of OWS protocol • Try to apply method to WebDAV (remote file access) expecting no issue • Same problem, with knobs on: – XML responses require URL rewriting – “Destination:” header in move requests contains URLs of WS (RequestHeader edit) – “Location:” response header is a bridge too far (Header edit, subst. string can’t be an env. var.)
  17. 17. Persevered for completeness • Façade-protected WebDAV partially working (issues with folder creation) – • Proper fix would be protocol-specific – Which is what we wanted to avoid
  18. 18. Lessons learned • Façade method depends on – “clean” application-level protocol – Or at least a well-understood one • Applying mechanically to arbitrary app protocol may lead to trouble • If you control (understand) the app: – Façade method may be applicable – Simple Apache config + scripts
  19. 19. Shibboleth approach • Recent work by Shibboleth core team and U. Chicago – Extends Shibboleth with delegated authentication • User logs in to “portal” (SP#1) • Using IdP with delegation plug-in • SP#1 app invokes web service at SP#2 • SP#2 gets user attributes without login there • Library lets portal app transparently forward SP#2 authN request back to IdP
  20. 20. Current work • Install/configure required components SP#1 /portal library tomcat shibd SP#2 /ws tomcat shibd IdP /idp tomcat, deleg. plug-in Dev. Env. (/portal, /ws) Eclipse Maven2 ECP/PAOS using SP#1’s authN assertion