1. Fundamentals: Security, Privacy, Trust

2. Scenarios we’d like to see... Use of licensed library materials regardless of student’s location Signed email Stronger, more secure authentication procedures where needed Encrypting of documents and email as appropriate Fewer accounts/passwords per user Authentication of individuals for desktop videoconferencing, chat, other collaboration tools Inter-institutional courses sharing web sites without additional user or faculty overhead Portals acting on our behalf Digital signatures and work flow Access based on roles instead of hard-coding in user names And more….

3. Key Concepts Security - protecting servers, communications, networks, hosts, personal information; has distinct authentication and authorization needs Privacy – moving from passive privacy to active privacy Trust - the continuum of trust and how communities use trust models Identity Service Providers – to broker external uses of authentication and authorization, respecting security and privacy, in an appropriate trust fabric Authentication and Authorization architectures technologies

4. Security of networks (denial of service, physical infrastructure) of hosts (OS bugs, mis-settings, etc.) of personal information and communication (signed and encrypted email, directory protection, etc,) some technologies (PKI, firewalls, etc.) can serve several areas

5. Key security issues cost/benefit ratio in money cost/benefit ratio in functionality the human factors complexity and ease of use mobility multiple systems and contexts think globally, act inconsistently

6. Rethinking Privacy As Bob Blakely says, “It’s not about privacy, it’s about discretion.” Passive privacy - The current approach. A user passes identity to the target, and then worries about the target’s privacy policy. To comply with privacy, targets have significant regulatory requirements. And no one is happy... Active privacy - A new approach. A user (through their security domain) can pass attributes to the target that are not necessarily personally identifiable. If they are personally identifiable, the user decides whether to release them. Who will be happy?

7. Rethinking Privacy For access to controlled resources, there is a spectrum of approaches available. At one end is authorization approach, where attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach supports privacy. At the other end is the authentication approach, where the identity of a prospective user is passed to the controlled resource and is used to determine (perhaps with requests for additional attributes about the user) whether to permit access. Since this leads with identity, this approach requires the target to protect privacy.

8. Business Issues and Active Privacy When does a company want to know identity versus behavior? How many people register software? Does software support depend on the user or the attribute “have a registered copy of the software?” When a company wants to know identity, what will it take for the user to reveal it? Obvious business requirement Compelling ease of use for the user (A rubber squeeze toy) Think of how popular cash is despite the convenience of credit

9. The Continuum of Trust Collaborative trust at one end… can I videoconference with you? you can look at my calendar You can join this computer science workgroup and edit this computing code Students in course Physics 201 @ Brown can access this on-line sensor Members of the UWash community can access this licensed resource Legal trust at the other end… Sign this document, and guarantee that what was signed was what I saw Encrypt this file and save it Identifiy yourself to this high security area

10. Dimensions of the Trust Continuum Collaborative trust handshake consequences of breaking trust more political (ostracism, shame, etc.) fluid (additions and deletions frequent) shorter term structures tend to clubs and federations privacy issues more user-based Legal trust contractual consequences of breaking trust more financial (liabilities, fines and penalties, indemnification, etc.) more static (legal process time frames) longer term (justify the overhead) tends to hierarchies and bridges privacy issues more laws and rules

11. Interrealm Trust Structures Federated administration basic bilateral (origins and targets in web services) complex bilateral (videoconferencing with external MCU’s, digital rights management with external rights holders) multilateral virtual organizations and Grids Hierarchies may assert stronger or more formal trust requires bridges and policy mappings to connect hierarchies appear larger scale

12. Simple point-to-point model client Enterprise LDAP directory Attribute authority Authentication Service target Attribute requestor Policv decision point Policy enforcement point Policy enforcement point Policy enforcement points Video directory Service discovery service Protocols Grid directory Video directory Enterprise LDAP directory

13. Trust in Transactions In a business transaction The user trusts the origin to faithfully represent its attributes to targets and obey privacy rules The origin trusts the user to obey its authentication and authorization rules The target trusts the origin to accurately manage and communicate user attributes and respect the user’s privacy settings The origin trusts the target to take the appropriate transaction actions and to not misuse the user’s information.

14. The Trust Continuum, Applications and their Users Applications and their user community must decide where their requirements fit on the trust continuum Some apps can only be done at one end of the continuum, and that might suggest a particular technical approach. Many applications fit somewhere in the middle and the user communities (them that trust each other) need to select a approach that works for them.

15. Mapping the issues: (a slide for Annie…) Collaborative TrustLegal Trust Security Privacy

16. Identity Service Providers An emergent service need Serves as an electronic broker for users to other service providers (content providers, web servers, calendar services, e- commerce, etc,) Protects users, their resources and their privacy Typical folks will have a handful: work, home, private Potential suppliers are: businesses (either in-house or out- source), desktop operating systems (Microsoft), ISP’s (AOL), banks, other...

17. Authentication and Authorization Authentication Authorization the sources of confusion

18. The Architecture of Authentication Identification/Authentication has two components the initial determination that a particular subject should be provided a specific credential (identification). i.e. “getting a credential” the continuing processes of that subject establishing their electronic presence (authentication) “using a credential” Examples two forms of photo id in person to be issued a computer account, and then Kerberos to authenticate providing a name and social security number to receive a PIN, and being able to view student loan data with that PIN The “strength” of authentication depends on both processes The need for strong authentication depends on the resources that are being offered to the authenticator

19. The Architecture of Authorization Should the authorization decision be made by the user’s domain, based on business rules provided by the target or by the target, based upon attributes provided by the user’s domain? If at the target, should the user’s domain pass all attributes about a user to a target, to protect the privacy of the target, or a minimal set of attributes, to protect the privacy of the user? The answers depend on point of view, scalability, manageability, and performance

20. We Need A Strong Authentication Service Identity in the real world is very hard. There are some legitimate needs that need formal and high levels of security services Documents must be notarized There are cases where email be signed and encrypted Authentication is in general a “local” service that can be conveyed globally

21. We Need a Flexible Interrealm Authorization Service We are only beginning to understand authorization Permissions are much more volatile than identity Delegation and non-determinism are hard Privacy rests here, and we don’t understand privacy Expressions of permissions require complex data structures

22. Layclergy Rules of Thumb X.509 for strong authentication/legal trust SAML/Shibboleth for flexible authorization/collaborative trust Note that X.509 can be used for authorization SAML/Shibboleth can exchange that someone was authenticated Neither is necessarily wise but neither is unavoidable