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

352

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
352
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

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 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

×