Presentation given by Fiona Culloch at FAM10 on 6 October 2010

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