From UW Center for Collaborative Technologies Wiki
Jump to: navigation, search

Identity Management, Access Control and Security Notes

  • We would like to support integration with a widely used federated inter-realm identity management system such as OpenID , Shibboleth, Windows Live ID, etc..
  • We would like to be able to "plug-in" different authentication providers. For example, if a site does not participate in Shibboleth, we should still provide a way for users at the site to acquire credentials and access tokens, and participate in conferences as authenticated users.
  • The concept of anonymous or unauthenticated user would exist, and these users could be given rights as needed. The anonymous user would always be able to access certain public venues and services in order to encourage experimental use of the system.
  • Consumers of access tokens would include all of the CXP services. Providers of venues (static or dynamic) may have access constraints on venue scheduling, and may allow the scheduler or admin to identify other allowed participants. Archive services may permit only certain participants to create archives, and may restrict who may initiate archive playback. Reflector services may be configured by an admin to restrict access to particular users.
  • Archives may be protected. An archived conference might include a playback ACL. A simple approach would be to attach a password to an archived conference.
  • We would like to support Group paradigm in order to more easily manage access.
  • We would like as much as possible for the UI to accurately represent to the user the true level of security currently in effect. For example icons should indicate whether a venue is public or restricted. Icons representing authenticated users should be clearly different from those of unauthenticated users. If there are multiple authentication providers, it should be easy to for all users to see how other participants were authenticated.
  • Since the sender can't control where multicast may go, implementing security beyond a trivial level when using multicast will require stream encryption.

Password-enabled Archive Service

Following are three designs for a simple low-security password-enabled archive service. A significant design constraint is that these should not involve breaking changes with ConferenceXP 5.0. This will be enabled partly by the existence of the 'GetVersion' API in the 5.0 Archive Service. This will allow the updated client to determine if password-enabled APIs should be used. The additional complexity of supporting legacy clients can be removed prior to ConferenceXP 6.0. Note that in the first two cases, the password hash could easily be sniffed on the network, and reused by a malicious user who does not know the password, so these designs provide only very minimal security.

The first design would allow setting a password when creating the archive. The admin tools would be enabled for setting/resetting or clearing the per-conference password, and a password hash would be stored in the database. The playback UI would change so that details of protected conferences would not be shown until the correct password was entered. Unprotected conferences would play without a password. The legacy client would only create unprotected archives, and would only be able to play back unprotected archives. The updated client would query the server version, and if the server was password-enabled, it would use different APIs and a different UI to create and play back archives, prompting for passwords as necessary. The updated client working with the old Archiver would use legacy APIs and legacy UI.

The second design would enable the admin tool to set one password for the entire server. The updated client when working with updated server would use a new API to find out if the password was set, prompt for it, and send it to the server. The updated server with a password set would return no conferences to the legacy client. There would be no changes to the recording process or to the database.

The third design would use a password to generate a symmetric encryption key. This design would provide strong security, by ensuring that all content on disk and on the wire is encrypted. It would be possible to use encryption with either of the aforementioned strategies (per-server or per-session passwords). Alternately, one could apply encryption on a per-venue basis. This has the advantage of being able to leverage the existing venue password mechanism. Indeed, this would probably be the most secure option, since the archiver would never "see" non-encrypted content.

Notes on Shibboleth

  • The Shibboleth website is here: Shibboleth
  • The Shibboleth architecture consists of the following agents:
    • Identity Provider (IdP). The IdP is likely to be the owner of an existing User account database, and has the ability to authenticate users for an organization. Typically each participating university would run the IdP centrally, for instance UW C&C currently supports a Shibboleth IdP for UWNetID logins.
    • Service Provider (SP). The SP runs on a webserver that hosts the resources in need of access control. In the case of Windows IIS, the SP takes the form of an ISAPI filter and a Windows service called shibd.
    • WAYF Service. (Where Are You From). This optional service maintains a list of sites involved in a Shibboleth federation. The role of the service is to give the user who wants to use a protected resource on a SP a way to redirect to the appropriate IdP to login. The applications themselves can also perform this function.
    • User agent -- Normally a standard web browser. When the browser attempts to use a protected resource on a SP, it is redirected to a WAYF which allows the user to indicate his or her organization. Next the browser redirects to the IdP for the organization where a login prompt is presented. After a successful login, the browser redirects back to the original resource on the SP where the users attributes can be applied to determine the level of access.
  • Other features and concepts:
    • A Shibboleth Federation is a grouping of Shibboleth sites which want to share resources. A significant federation to which UW belongs is called InCommon. InCommon is focused on higher education institutions in the US (currently). Corporate sites can also join if they have a sponsor. One member of InCommon is ProtectNetwork. This organization provides authenticated individual Shibboleth credentials for a fee, or free unauthenticated credentials.
    • The process of setting up a new SP is complicated by the fact that in general the IdP's won't share any identity information until the SP has been added to their security policy. Sites are generally very protective of user identity information.
    • The role (or a role) of shibd on the SP is to implement the Shibboleth Attribute Requestor (SHAR). This forms a communication backchannel between SP and IdP for the purpose of retrieving additional attributes. By default shibboleth leads with a minimal set of information about authenticated users in order to protect privacy. Additional attributes need to be explicitly requested and authorized.
    • A decent looking Windows IIS SP installation page is here. Note the 'TestShib' link toward the bottom.

Notes on OpenID

  • OpenID is an emerging decentralized identity framework which appears to be gaining popularity. OpenID. The Wikipedia Article has a good overview.
  • Terminology: The Service Provider is known as the "relying party" (RP). The Identity Provider is the "OpenID Provider" (OP).
  • Architecture in a nutshell: The user owns a URI which is entered on an RP web form to begin the login. The URI in turn contains some information about the user's OP. The RP and OP establish a secure channel with a shared secret. At this point the user may authenticate with the OP, and indicate to the OP that he or she authorizes the RP to know his or her identity. The OP communicates the results to the RP, and the RP applies authoriztion rules.
  • OpenID differs from Shibboleth in that Federations do not exist. Since anyone can run their own OP, establishing trusted identity is outside the scope of the framework. This could probably be mitigated if a RP uses only particular OPs which are believed to be trustworthy.
  • A free OpenID is available here