0
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 service...
The requirement
• Browser-based federated SSO
protocols require:
– HTTP redirection
– Cookies
– SSL/TLS
– User input (user...
The problem
• Web service clients may support none
of these requirements. Consider:
– Floating, “back end” client process
...
The consequence
• Web services generally do not support
federated authentication
– Talking about plain HTTP web services
–...
First approach: “façade” concept
• Separate:
– Client data flow (XML over HTTP)
– From browser auth flow (HTML, SAML over
...
“Façade” is an authenticating proxy
WS
Façade
Client
http://proxy/...438657...XML
XML
Façade has two faces
WS
Façade
Client
http://url1/...438657...XML
XML
BrowserSAML
HTM
L
SP
http://url2/...438657...
In practice
• First step: browser login to façade SP
– Standard Shibboleth IdP/SP flow
– Façade authorizes (here using ePS...
Copy access link
• Paste URL into client application
Unmodified client accesses WS
• Via façade, using URL with token
– Not via Shibboleth
Implementation methods
• In previous work, façade was:
– Java servlet
– Bespoke SAML SP implementation
• Shared tokens wit...
Use Apache as façade
• Does URL contain /session/nnn/xxx ?
– No: reject (Forbidden)
– Yes: replace by /ws/xxx
• RewriteMap...
Problem with façade concept
• What if a web service response
contains URLs of WS endpoints?
– Client may try to access tho...
Rewriter implementation
• Problem not theoretical: affects Web Map
Service example above (GetCapabilities)
• Original serv...
Problem more general than thought
• Thought GetCapabilities was odd accident of
OWS protocol
• Try to apply method to WebD...
Persevered for completeness
• Façade-protected WebDAV partially
working (issues with folder creation)
– http://edina.ac.uk...
Lessons learned
• Façade method depends on
– “clean” application-level protocol
– Or at least a well-understood one
• Appl...
Shibboleth approach
• Recent work by Shibboleth core team and U.
Chicago
– Extends Shibboleth with delegated authenticatio...
Current work
• Install/configure required components
SP#1
/portal
library
tomcat
shibd
SP#2
/ws
tomcat
shibd
IdP
/idp
tomc...
Upcoming SlideShare
Loading in...5
×

The WSTIERIA Project – A Web of Services

371

Published on

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
371
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "The WSTIERIA Project – A Web of Services"

  1. 1. The WSTIERIA Project – A Web of Services 6 October 2010 Fiona Culloch fiona.culloch@ed.ac.uk
  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: – http://edina.ac.uk/projects/wstieria/files/TN01-facad
  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) – http://edina.ac.uk/projects/wstieria/files/TN0 • 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×