200 likes | 301 Views
Mind the Gap (And Try To Fill It with Any Tool at Hand) Bridging PAPI and A pplications. Diego R. Lopez. The Goals. Web SSO does not stay at its bare bones Control the access to restricted areas Pass identity data to Web-based applications From CGI to servlet And beyond
E N D
Mind the Gap (And Try To Fill It with Any Tool at Hand) Bridging PAPI and Applications Diego R. Lopez
The Goals • Web SSO does not stay at its bare bones • Control the access to restricted areas • Pass identity data to Web-based applications • From CGI to servlet • And beyond • Web enabled applications • Use the browser to establish the initial identity context • Current technology makes it perfectly possible • Albeit there is a gap with application developers
The Gap • Web SSO and applications developers seem to be minded in different ways • Middleware and server in one side • Match with server procedures and identity sources • An end by itself • Business rules on the other side • Databases and tiers • A means to an end • So they expect for us at their side of gap • Here is the true story of PAPI travel to application-land
The Starting Point • PAPI runs as an Apache module • Traditional Apache methods were used • To pass data through other modules up to the application • Notes • Shared-memory inter-module communication • Headers • As if they were coming in the original request • Authentication parameters • As if they were established by HTTP Auth procedures • In any possible flavor • The whole, unprocessed, assertion • Individual attribute values
The Staring Point. Some Details • Notes and headers • The whole PAPI assertion is available through • Note PAPIHcook • Header X-PAPI-Hcook • PAPIAttr-<ATTNAME> in notes PAPIAttr-schacMotherTongue • X-PAPIAttr-<ATTNAME> in headers X-PAPIAttr-schacMotherTongue • HTTP Auth values • New to PAPI 1.5 • Using the directive MapAuthUser to apply the appropriate attribute value
Going a Little Beyond • Less HTTP-ish detail • Avoid header processing • Do not require tweaking the server configuration • Configuration independence for each instance • Provide an abstraction layer • General interface to access attributes, independently of the source • Avoid future protocol changes affecting application code • Finer control • Apply to other units that those supported by the Apache module • And available in many flavors • Do not mandate a particular implementation language
The PAPI Model at Play uid=drlopez role=admin Directory Server uid=drlopez role=admin Assertion Formats uid=drlopez AuthServer AuthN Data uid: drlopez pass: ****** GPoA RedIRIS PoA Intranet PoA Admin
Applying the PAPI Model • The Authentication Server (AS) => IdP • Provides users with a (local) single authentication point • Source for user attribute data • The Point of Access (PoA) => inner SP • Performs actual access control by means of temporary cryptographic tokens, encoded as HTTP cookies • The Group-wide Point of Access (GPoA) => outer SP • Combines a group of PoAs with similar access policies • Intended to simplify AS-PoA interactions and PoA operation • PoAs relaying on a GPoA can be built using different language bindings with a relatively low effort • And a standalone GPoA based on AA-RR is also available
phpPoA • Requires a parent GPoA • Implemented as a PHP (4/5) object • Takes care of HTTP redirections mandated by the PAPI protocol • Must be instantiated and called at the start of the procedure • Provide access control and attribute access to individual pages • Configured through a typical PHP ini file • Unique for all the phpPoAs running in the server • Easy to use for those who are PHP-aware [admin] Location = /admin LKEY_File = /usr/local/papi/etc/KEYS/lkey GPoA_Pub_Key = /usr/local/papi/etc/KEYS/_GPoA_pubkey.pem GPoA_URL = http://www.rediris.es/papiGPoA/papiPoA PAPI_Filter_accept = "group=tecniris,.*?uid=david" PAPI_Filter_reject = ".*"
The phpPoA Interface • A simple method call $poa = new PoA('admin'); // Stanza in phpPoA.ini $attr = $poa->check_Access(); • Returns an associative array with the authorization results and the received attributes PAPIAuthZValue => 1 PAPIASName => myAuthNServer PAPIAssertion => uid=myUID,group=myGID,role=admin@myAuthNServer uid => myUserID group => myGroupID role => admin
es.rediris.papi.filter • A Tomcat filter based in the same principles as phpPoA • Configured through an XML properties file • Configurable for each PAPI filter in the system • Easy to use for those who are Tomcat-aware <properties> . . . <entry key="PoAkeys.lkeyName">/home/tomcat/conf/PAPI/lkey</entry> <entry key="PoAconf.location">/servlets-examples/</entry> <entry key="PoAconf.cookieFile">cookies.txt</entry> <entry key="PoAconf.POST_Method">manual</entry> <entry key="PoAconf.PAPI_Filter">any => accept</entry> <entry key="PoAconf.attSeparator">,</entry> <entry key="PoAconf.attValSeparator">=</entry> . . . </properties>
The es.rediris.papi.filter Interface. Configuration • Define it in the web.xml Tomcat configuration file <filter> <filter-name>PAPI Filter</filter-name> <filter-class> es.rediris.papi.filter.PAPIFilter </filter-class> <init-param> <param-name>PAPI.configFile</param-name> <param-value>/home/tomcat/conf/PoAconf.xml</param-value> </init-param> </filter> . . . <filter-mapping> <filter-name>PAPI Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
The es.rediris.papi.filter Interface. Runtime • Implementation of the javax.servlet.Filter interface • Constructor plus init() and doFilter() methods • If authorization succeeds, attributes are made available through • Attributes in the user session maintained by the application context es.rediris.papi.filter.PAPIHcookValue => 1143987915:uid=myUID,group=myGID,role=admin@myAuthNServer es.rediris.papi.filter.PAPIAuthServer => myAuthNServer es.rediris.papi.filter.uid => myUserID es.rediris.papi.filter.group => myGroupID es.rediris.papi.filter.role => admin • Available to any servlet accessed in the same application context • A full implementation of JAAS to be directly referenced by servlets is under way
Going Beyond: JNLP/Java Web Start • A small JNLP application must be loaded • Living in a PAPI-protected location • Fresh cryptographic material is passed as parameter • Establish the PAPI tokens through a shared cookie repository • Using the standard class HTTPClient • Any data access from JNLP applications can then be protected by PAPI • Referencing URLs behind a PAPI PoA • Just by using the HTTPClient class for network connections • And this is orthogonal with protecting the access to the application itself • Putting the XML definition in an URL behind a PAPI PoA
If Anything Else Fails: RewritingProxy • A proxy with rewriting capabilities • Supporting several access methods • IP address • HTTP (basic and digest) authentication • Forms • Able to: • Proxy sites or entire domains • Be seen as a virtual host or a location • Integrate with a cache to enhance response times • Include user attributes to fulfill access methods • Usernames, passwords, source IP addresses,…
The RewritingProxy Engine • The rewriting engine can be applied to: • HTML tags plus embedded scripts (JavaScript, CSS) (always) • Specific content types • URL patterns (even bypassing PAPI access control) • The rewriting engine is based on: • Perl regular expressions • Derived from the remote site or domain being accessed • Specific, applicable to • The whole proxied site/domain • URLs matching certain patterns • Attributes can be used inside the engine
RewritingProxy At Work: From Simple… • Remote site # REL 1, 20030101 Remote_URL http://portal.acm.org • Remote domain # REL 1, 20030101 - Requires PAPI >= 1.2.0 Remote_Domain ebsco.com PAPI_Redirect ([\w-]+).ebsco.com PROXYNAME/$1/
RewritingProxy At Work: …To More Sophisticated… • A little bit # REL 2, 20050627 - Requires PAPI >= 1.3.0 Remote_Domain iop.org PAPI_Redirect ([\w]+).iop.org PROXYNAME/$1 PAPI_Redirect "/images "/$name_dest/images Rewrite_MIME_Types application/x-javascript • And more # REL 2, 20040602 - Requires PAPI >= 1.3.0 Remote_Domain aip.org PAPI_Redirect ([\w]+).aip.org PROXYNAME/$1/ PAPI_Redirect PROXYNAME/([\w]+):([\d]+) PROXYNAME:$2/$1 PAPI_Redirect \"/jimages/ \"/$name_dest/jimages/ PAPI_Redirect \"/vsearch/ \"/$name_dest/vsearch/ PAPI_Redirect \"/journal_cgi/ \"/$name_dest/journal_cgi/ PAPI_Redirect SRC='/journals/ SRC='/$name_dest/journals/ Rewrite_MIME_Types application/x-javascript
RewritingProxy At Work: …To Really Complicated # REL 5, 20050627 - Requires PAPI >= 1.4.0 Remote_Domain isiknowledge.com No_XML 1 # Mark URI-escaped characters PAPI_Redirect %(25)?([0-9a-fA-F]{2}) *$1$2* . . . # URLs with port spec PAPI_Redirect PROXYNAME/([\w]+)(/|\*2F\*)?(:|\*3A\*)(8080)(/|\*2F\*) $1.isiknowledge.com$3$4$5 . . . # Rewrite back "product references" into URL params PAPI_Redirect product_st_thomas=(.*?)PROXYNAME(:|\*3A\*)?([\d]+)?(/|\*2F\*)(.*?)(/|\*2F\*) product_st_thomas=$1$5.isiknowledge.com$2$3$4 . . . # Unmark URI-escaped characters PAPI_Redirect \*(25)?([0-9a-fA-F]{2})\* %$1$2 . . .
RewritingProxy In the Run • The need for proxying is going to stay during (at least) some years • So we’d better prepare for it • Community support for proxy definitions • All the examples previously shown are available at http://papi.rediris.es/comu/proxies/ • Ongoing enhancements • Proxy auto-configuration from definitions held at the PAPI site • Applet proxy