Emergency Alerts as RSS Feeds with Interdomain Authorization

1
Emergency Alerts as RSS Feeds with Interdomain
Authorization

• Filippo Gioachin1, Ravinder Shankesi1, Michael J.
  May1,2, Carl A. Gunter1, Wook Shin1
• 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
Emergency Messaging
alerts
alerts
auth
5
Emergency Messaging

• Roles
• Permission
• Location
• Employer
• Specialty

alerts

• Policies for permissions
• Access Control Lists

• Alert policies
• Permissions
• Scope
• Location

6
Emergency Messaging
auth
token
alerts
Alerts summary
token

• 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
Alert Database
Public Health Directory
Alert Filter
Policies
7 Alerts
6
3
4
Alerts to RSS
8 RSS
1 Redirect
1 Req
2 Auth
5
Identity Provider
5 Token
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
• http//seclab.uiuc.edu
• Shibboleth RSS Project
• http//seclab.uiuc.edu/securerss
• Demo video
• http//seclab.uiuc.edu/resources/shibbolethRSSDemo
  .html
• Or Google Shibboleth RSS

18
High Level Architecture