Transcript WSTIERIA Project - A Web of Services

The WSTIERIA Project –
A Web of Services
6 October 2010
Fiona Culloch
[email protected]
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
The requirement
• Browser-based federated SSO
protocols require:
– HTTP redirection
– Cookies
– SSL/TLS
– User input (usernames, passwords, etc.)
– HTML processing
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
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
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
“Façade” is an authenticating proxy
Client
XML
http://proxy/...438657...
Façade
XML
WS
Façade has two faces
Client
XML
http://url1/...438657...
Façade
XML
SP
SAML Browser
HTML
http://url2/...438657...
WS
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
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 with servlet via in-memory DB
• WSTIERIA:
– Saw similarity to standard HTTP proxy
– Investigated off-the-shelf solutions
– Pursued Apache + mod_rewrite
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.
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…
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/TN01facade.pdf
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.)
Persevered for completeness
• Façade-protected WebDAV partially
working (issues with folder creation)
– http://edina.ac.uk/projects/wstieria/files/T
N02-webdav.pdf
• Proper fix would be protocol-specific
– Which is what we wanted to avoid
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
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
Current work
• Install/configure required components
IdP
SP#1
/idp
tomcat,
deleg.
plug-in
/portal
library
tomcat
shibd
SP#2
/ws
tomcat
shibd
ECP/PAOS using
SP#1’s authN
assertion
Dev. Env.
(/portal,
/ws)
Eclipse
Maven2