The WSTIERIA Project – A Web of Services
•Download as PPT, PDF•
0 likes•598 views
The WSTIERIA Project aims to enable federated authentication for web services without requiring browser-based protocols. The initial "facade" approach uses an Apache proxy that redirects authenticated browser sessions to rewrite URLs in web service responses. However, this approach has limitations when applied to arbitrary protocols due to dependencies on URLs. The project is now exploring using Shibboleth's delegated authentication extension, which allows a portal application to transparently authenticate a user to a backend web service without further login.
Report
Share
The WSTIERIA Project – A Web of Services
- 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 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: – http://edina.ac.uk/projects/wstieria/files/TN01-facad
- 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) – http://edina.ac.uk/projects/wstieria/files/TN0 • 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