1 / 20

The WSTIERIA Project – A Web of Services

The WSTIERIA Project – A Web of Services. 6 October 2010 Fiona Culloch fiona.culloch@ed.ac.uk. Project context. Previous EDINA (geo) web services authentication work (SEE-GEO project) EDINA Digimap uses web services in back end

dermot
Download Presentation

The WSTIERIA Project – A Web of Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The WSTIERIA Project – A Web of Services 6 October 2010 Fiona Culloch fiona.culloch@ed.ac.uk

  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 clientsmay 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 Client XML http://proxy/...438657... Façade XML WS

  8. Façade has two faces Client XML http://url1/...438657... Façade SP Browser SAMLHTML XML WS 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:fileRewriteRule ^/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: http://edina.ac.uk/projects/wstieria/files/TN01-facade.pdf

  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 headeris 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) http://edina.ac.uk/projects/wstieria/files/TN02-webdav.pdf 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 IdP/idptomcat,deleg.plug-in SP#1/portallibrarytomcatshibd SP#2/wstomcatshibd Dev. Env.(/portal,/ws)EclipseMaven2 ECP/PAOS using SP#1’s authN assertion

More Related