1 Emergency Alerts as RSS Feeds with Interdomain Authorization Filippo Gioachin 1, Ravinder Shankesi 1, Michael J. May 1,2, Carl A. Gunter 1, Wook Shin 1 1 University of Illinois Urbana-Champaign 2 University of Pennsylvania

2 Emergency Messaging Emergency messaging has requirements we see in other contexts as well Scalability Timeliness Targeted delivery Public health emergency messaging has additional requirements Sender integrity and authentication Message integrity Recipient integrity and authentication Wide scale distribution with targeted delivery We need interdomain messaging with multiple levels of authentication

3 Emergency Messaging

4 auth alerts

5 Emergency Messaging alerts Roles Permission Location Employer Specialty Policies for permissions Access Control Lists Alert policies Permissions Scope Location

6 Emergency Messaging alerts auth token Alerts summary Attribute based policies Summaries

7 Our approach Leverage existing technologies for a scalable interdomain authentication and authorization system Rights as user attributes Policies given in terms of attributes Interdomain federation and trust between state authorities and local organizations Alerts as messages with policies Policies based on CDC standardized messaging format Policies defined by CDC, enforced by states Alerts provided as summaries Natural mechanism for regularly updating and dynamic content

8 Our approach Shibboleth attribute based authentication SAML token based Users authenticate to a local Identity Provider (IdP) which provides a signed attribute cookie Users use the cookie to authenticate to the service provider RSS based message feeds XML based message summary format Widely deployed mechanism for distributing links to dynamically updated content SSL encryption between nodes Result: Shibboleth RSS

9 Contributions Architecture and implementation of Shibboleth RSS Application to standards based messaging formats Scalability and performance estimates from experiments

10 Design Considerations What attributes to consider? Attributes from CDC message format - Common Alerting Protocol (CAP) and Public Health Directory Schema (PHINDir) What workload to put on server and client? RSS from CAP on the server RSS to HTML done on client Custom user filtering done with JavaScript on client How to design policies? Forcing redesign of policies are a burden on alert authors Generic policies will match most messages and speed policy filtering Custom policies can be attached if desired

11 Policy Evaluation System architect predefines common policies Policy names are associated with each alert Policies need to be evaluated only once per request User attributes compared once against existing policies and stored for later use

12 High Level Architecture 1 Req 1: Redirect Identity Provider Public Health Directory 2: Auth 34 5: Token Alert Filter Alert Database Policies Alerts to RSS 6 5 7: Alerts 8: RSS

13 Performance Evaluation Vary the number of policies and number of alerts Alerts Small = 128 Kb (54 infos in 15 alerts) Big = 512 Kb (216 infos in 60 alerts) Policies Few = 10 rules Many = 50 rules Critical operations SSL tunnel establishment PHP web page processing Policy evaluation Message filtering based on policy Summarizing messages in RSS Transforming RSS to HTML for viewing

14 Performance Evaluation Downloads per second

15 Performance Evaluation Optimizations: CAP to RSS feed format Cached policies per user Searched for all policies at once Results: SSL the biggest performance hit Size of the input matters, not number of policies Downloads per second

16 Conclusion Shibboleth RSS offers a scalable method for interdomain emergency alerts Attributes let us define policies RSS lets us summarize policies for reading Performance penalty reasonable after SSL About 45% - 60% throughput Federated trust makes interdomain messaging practical

17 References Illinois Security Lab Shibboleth RSS Project Demo video SDemo.htmlhttp://seclab.uiuc.edu/resources/shibbolethRS SDemo.html Or Google “Shibboleth RSS”

18 High Level Architecture