3rd EuroCAMP Ljubljana Mind the Gap (And Try To Fill It with Any Tool at Hand) Bridging PAPI and Applications Diego R. Lopez

3rd EuroCAMP Ljubljana

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

AuthN Datauid: drlopezpass: ******

AssertionFormats

Directory Server

AuthServer

GPoA RedIRIS

PoA Intranet

PoA Admin

uid=drlopez

uid=drlopez

role=admin

uid=drlopezrole=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 = /adminLKEY_File = /usr/local/papi/etc/KEYS/lkeyGPoA_Pub_Key = /usr/local/papi/etc/KEYS/_GPoA_pubkey.pemGPoA_URL = http://www.rediris.es/papiGPoA/papiPoAPAPI_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 attributesPAPIAuthZValue => 1PAPIASName => myAuthNServerPAPIAssertion => uid=myUID,group=myGID,role=admin@myAuthNServer

uid => myUserIDgroup => myGroupIDrole => 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 contextes.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, 20030101Remote_URL http://portal.acm.org

Remote domain# REL 1, 20030101 - Requires PAPI >= 1.2.0Remote_Domain ebsco.comPAPI_Redirect ([\w-]+).ebsco.com PROXYNAME/$1/


RewritingProxy At Work: …To More Sophisticated…

A little bit# REL 2, 20050627 - Requires PAPI >= 1.3.0Remote_Domain iop.orgPAPI_Redirect ([\w]+).iop.org PROXYNAME/$1PAPI_Redirect "/images "/$name_dest/imagesRewrite_MIME_Types application/x-javascript

And more# REL 2, 20040602 - Requires PAPI >= 1.3.0Remote_Domain aip.orgPAPI_Redirect ([\w]+).aip.org PROXYNAME/$1/PAPI_Redirect PROXYNAME/([\w]+):([\d]+) PROXYNAME:$2/$1PAPI_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.0Remote_Domain isiknowledge.comNo_XML 1# Mark URI-escaped charactersPAPI_Redirect %(25)?([0-9a-fA-F]{2}) *$1$2*. . .# URLs with port specPAPI_Redirect PROXYNAME/([\w]+)(/|\*2F\*)?(:|\*3A\*)(8080)(/|\*2F\*) $1.isiknowledge.com$3$4$5

. . .# Rewrite back "product references" into URL paramsPAPI_Redirect product_st_thomas=(.*?)PROXYNAME(:|\*3A\*)?([\d]+)?(/|\*2F\*)(.*?)(/|\*2F\*) product_st_thomas=$1$5.isiknowledge.com$2$3$4

. . .# Unmark URI-escaped charactersPAPI_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

Documents

3rd EuroCAMP Ljubljana Mind the Gap (And Try To Fill It with Any Tool at Hand) Bridging PAPI and Applications Diego R. Lopez