Your SlideShare is downloading. ×
The  WSTIERIA Project – A Web of Services
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The WSTIERIA Project – A Web of Services


Published on

Presentation given by Fiona Culloch at FAM10 on 6 October 2010

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. The WSTIERIA Project – A Web of Services 6 October 2010 Fiona Culloch
  • 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. The requirement • Browser-based federated SSO protocols require: – HTTP redirection – Cookies – SSL/TLS – User input (usernames, passwords, etc.) – HTML processing
  • 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. 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. 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. “Façade” is an authenticating proxy WS Façade Client http://proxy/...438657...XML XML
  • 8. Façade has two faces WS Façade Client http://url1/...438657...XML XML BrowserSAML HTM L SP http://url2/...438657...
  • 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. Copy access link • Paste URL into client application
  • 11. Unmodified client accesses WS • Via façade, using URL with token – Not via Shibboleth
  • 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. 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. 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. 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. 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. 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. 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. 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. 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