- Do I need Shibboleth?
- How are users authenticated by Shibboleth?
- Who can authenticate to my application using Shibboleth?
- What sort of user identifiers and attributes are available to my applications?
- How do I authorize/limit access to my application using Shibboleth?
- How long do user sessions last and is there an inactivity timeout?
- Does Shibboleth support logout?
Shibboleth is of interest if you're supporting a web application that needs to authenticate its users, especially if the population is drawn from the faculty, staff, or students of LSU or other educational institutions in the InCommon federation . Shibboleth will enable users to login with their university-supplied network access account but avoids the need for your application to validate or manage passwords. Various kinds of attribute information about users can also be provided to your application for personalization or authorization (determining what information a user can access).
The answer to this question is complicated, because it depends on the procedures of the user's identity provider. In the case of most LSU-affiliated users, authentication is currently based on a username and password, typically using the myLSU authentication service used for myLSU and other network services.
Also, Shibboleth allows (but does not require) your application to accept credentials from identity providers other than LSU. Therefore, authentication is ultimately a matter of local policy, and the practices and procedures of identity providers should be reviewed by service providers. Federations such as InCommon can help optimize this process by collecting and documenting such practices and encouraging sound approaches.
This is related to the previous question, and again, the answer ultimately depends on the identity provider(s) in question. Authentication to Shibboleth at LSU is now open to a variety of university-affiliated people, ranging from the faculty, staff, and students to university applicants, many of whom may never attend classes. The use of attributes for authorization is very important in protecting valuable information. Furthermore, the IT Security and Policy Office can and will make no guarantees whatsoever about the kinds of accounts it may choose to issue in the future.
As a result, it is critically important that you understand the difference between authentication and authorization and that your application does not confuse the two. Many different kinds of users might be able to authenticate via Shibboleth. Your application cannot under any circumstances make any assumptions about who can or cannot authenticate or what privileges they might possess. If it helps, imagine that any creature in the universe might receive an account. Instead of making assumptions, your application should register for and examine attributes like eduPersonScopedAffiliation that can be used to distinguish LSU faculty and students from these more loosely affiliated users. This is part of authorization, and is a critical step you must take. It is not optional unless you simply don't care about who accesses your system, in which case, the use of Shibboleth is probably unnecessary to begin with.
For a complete answer to this question, refer to the attributes page . Various kinds of authorization-related attributes may be sufficient if your application does not need to uniquely identify its users. With Shibboleth, unique identification of users is easy, but optional, increasing the privacy of the user community. When unique and persistent/repeatable identification of users is required, a range of attributes can be used, depending on the application's requirements.
Shibboleth offers new approaches that position a service provider for the future by supplying universally-qualified identifiers that suit a federated environment of multiple identity providers in which simple usernames can collide. A commonly supported identifier in higher education is called an eduPersonPrincipalName , and resembles a campus e-mail address (e.g., smith9999@lsu.edu ). Other universities' EPPN values may be somewhat different (and need not even contain a readable name on the left-hand side), but they are guaranteed to be unique at any given point in time and are a reasonable quick replacement for traditional usernames in access lists or tables.
Finally, SAML and Shibboleth can supply a new kind of specialized identifier designed to support persistent identification without compromising privacy. The eduPersonTargetedID attribute (modeled on the SAML 2 concept of a "persistent" identifier) enables a user to be repeatedly identified by an opaque string value that is specific to that user and that service. An advantage of this attribute, in addition to increased privacy protection for users, is that it carries an additional guarantee beyond the uniqueness of EPPN known as non-reassignment. That is, a service provider can be certain that a given value asserted to it by a particular identity provider will always refer to the same identity and will never be assigned to another. Another advantage is that the opaqueness eliminates a significant cause of identifier changes in response to changes in marital status, which can cause hiccups in service delivery.
Shibboleth is primarily an authentication system that provides attributes, but does not implement a great deal of authorization directly. It is designed primarily for dynamic applications that can interpret the attribute information as they see fit and apply it to make authorization decisions. However, a limited degree of static access control enforcement is possible (along with a pluggable interface for access control extensions).
For specific details about how to protect specific pages on your server and write access control rules, check out the deployment page.
The Shibboleth software allows you to control the time elapsed before sessions with your applications expire. A timeout based on inactivity with your applications can also be enforced. However, this is distinct from the lifetime of the overall session that enables single sign-on, and in most cases using a local timeout that is shorter than the overall period is not useful. The overall session lifetime enforced by the LSU identity provider is eight (8) hours. Other identity providers will have different policies.
Not at this time. It will be supported in a future release in a best effort fashion, but the distributed/single logout protocol that will be used is not intended for high-security environments that need true logout. Encouraging and documenting logout through desktop reset or browser exit is highly recommended and is a more effective guarantee that it will be achieved.
