current EZ Proxy version: 6.1.1 GA [SOURCE: 5.7.26] [Linux] [2017-Aug]

confirmed with IT@Sam specialist Westley Bachmeyer, 7/24/2019, that AllowVars and EncryptVars (for stanzas such as EBL and UpToDate that pass usernames back/forth) IS enabled in the master config file. KLM

SHSU EZProxy Database Config Menu:  https://login.ezproxy.shsu.edu/menu

SHSU EZProxy prefix:  https://ezproxy.shsu.edu/login?url= 

A standard EZ Proxy stanza template could look like this, with just the Title, URL, and Domain included:

T [enter database or journal name here]

U [enter complete URL here, starting with http://...]

D [enter just the domain here, without http://, www, or any slashes, such as “cabells.com”]

Some resources also require a Host line, which is *usually the same as the Domain line:

H [enter just the domain here, without http://, www, or any slashes, such as “cabells.com”]

If you’re entering an individual journal title, for packages like Oxford Journals that have individual domains and require them all to be listed, the format varies a little more often – it may look just like the above, or it may have “DJ” instead of “D”, or it may look more like the example below; if we already have other titles in the package listed, it’s pretty easy to just follow their example:

# Journal Name Goes Here

H [journal domain goes here, like abbs.oxfordjournals.org]

…And if anything needs to be more complex than THAT, then the vendor is usually providing it.

• Proxy Database Config Menu url:  https://login.ezproxy.shsu.edu/login?user=ngl 

• For Vendor test logins:
  • ​EBSCO
  • EBL
  • Gale
  • ValueLine
  • ACS
  • IEEE

Please see CORAL.  

• Use Onetime links to send the urls as secrets, rather than giving out usernames/passwords.

How Shibboleth Works: Basic Concepts

At its core Shibboleth works the same as every other web-based Single Sign-on (SSO) system. What distinguishes Shibboleth from other products in this field is its adherence to standards and its ability to provide SSO support to services outside of a user's organization while still protecting their privacy.

The main elements of a web-based SSO system are:

• Web Browser - represents the user within the SSO process
• Resource - contains restricted access content that the user wants
• Identity Provider (IdP) - authenticates the user
• Service Provider (SP) - performs the SSO process for the resource

Single Sign-on Steps

Step 1: User accesses the Resource

The user starts by attempting to access the protected resource. The resource monitor determines if the user has an active session and, discovering that they do not, directs them to the service provider in order to start the SSO process.

Step 2: Service Provider issues Authentication Request

The user arrives at the Service Provider which prepares an authentication request and sends it and the user to the Identity Provider. The Service Provider software is generally installed on the same server as the resource.

Step 3: User Authenticated at Identity Provider

When the user arrives at the Identity Provider it checks to see if the user has an existing session. If they do, they proceed to the next step. If not, the Identity Provider authenticates them (e.g. by prompting for, and checking, a username and password) and the user proceeds to the next step.

Step 4: Identity Provider issues Authentication Response

After identifying the user, the Identity Provider prepares an authentication response and sends it and the user back to the Service Provider.

Step 5: Service Provider checks Authentication Response

When the user arrives with the response from the Identity Provider, the Service Provider will validate the response, create a session for the user, and make some information retrieved from the response (e.g. the user's identifier) available to the protected resource. After this, the user is sent to the resource.

Step 6: Resource returns Content

As in Step 1, the user is now trying again to access the protected resource, but this time the user has a session and the resource knows who they are. With this information the resource will service the user's request and send back the requested data.

Federated Single Sign-on

If you have heard about Shibboleth you have probably also heard something about "federations" or "Federated Single Sign-on". The steps above are common to all SSO systems, but some of these systems are designed to only work when the Identity Provider and Service Provider are in the same organization, whilst others are designed to work regardless of whether the two components are in the same organization. Implementations that fall into the later category are said to implement Federated Single Sign-on.

It is not uncommon that a given Service Provider may wish to work with more than one Identity Provider (e.g. commercial services with multiple customers, resources used by researchers at multiple organizations), and likewise a given Identity Provider might wish to work with multiple Service Providers. When a group of Identity and Service Providers agree to work together, this group is called a federation.

How Shibboleth Works: Identity Provider Discovery, User Attributes and Metadata

Identity Provider Discovery

After reading Basic Concepts, you may have asked how a Service Provider working with multiple Identity Providers knows where to send an authentication request along with the user? The answer is that the user is asked and that prompt is known as Identity Provider Discovery.

Shibboleth offers two products that can be used to perform Identity Provider Discovery. The Embedded Discovery Service works with the Shibboleth Service Provider in order to display an identity provider selector UI that integrates with your site, whilst the Centralized Discovery Service is a standalone application that can be deployed centrally and to which Service Providers can delegate the work of presenting a selector UI. Service Providers are strongly encouraged to use the Embedded Discovery Service as it offers a far better user experience.

User Attributes

Another feature that most services take advantage of when using Shibboleth is the ability to receive data about the user from the Identity Provider. This data known as user attributes can be anything that the Identity Provider knows about the user and that may be helpful to the Service Provider. Some examples of this type of data are:

• User's email address or phone number;
• Groups to which the user belongs;
• Information about the user's role in the organization;
• Specific privileges a user has been granted.

The ability to preserve a user's privacy is a principal concern within all Shibboleth products. Both the Identity Provider and Service Provider allow the deployer to set attribute filter policies to address these concerns. Within the Identity provider this policy controls which attributes will be released to which Service Providers, whilst within the Service Provider this policy controls what information will be accepted from which Identity Providers.

Metadata

Another question you may have asked is if the SSO process is undertaken via HTTP, how do the Identity provider and Service Provider know which URLs to use when communicating with each other?. This function is accomplished by a metadata document that describes various technical aspects of an Identity Provider or Service Provider.

The metadata for an Identity Provider or Service Provider usually contains the following information:

• a unique identifier, known as an entity id;
• a human-readable name and description;
• a list of URLs to which messages should be delivered and some information about when to use each;
• cryptographic information used when creating and verifying messages.

A common function of a federation is to publish a file containing all the metadata for the Identity Providers and Service Providers that have agreed to work together, which is then made available to all participants. This way a Service Provider does not need to contact every Identity Provider when it changes its metadata (or vice versa), but simply provides it to the federation.

The Shibboleth software is open source and freely available, but ongoing development efforts to meet the needs of identity federations, educational systems and institutions have now grown to over $500,000 per year. Those making extensive use of the software should consider joining the consortium to ensure the continuity of Shibboleth as well as help shape its future. Membership investment is particularly important from R&E identity federations and commercial partners in order to support development, maintenance and support activities

Shibboleth Consortium
c/o Jisc Services Limited
Lumen House
Harwell Oxford
Didcot OX11 0SG
United Kingdom T +44 1235 822212
E contact@shibboleth.net

If you would like to report a potentially security sensitive issue with one of the products, please use the form or send an email to security@shibboleth.net.

If you have an administrative question about the Shibboleth Project or the Shibboleth Consortium, you may use the form also.

For technical questions or any form of software support, assistance, advice, etc., you MUST use the Users' Mailing List. We will not provide technical advice or support or answer technical questions if you use the form below. You may get a response to this effect, but we will not provide support other than through the mailing list. Open source software requires community involvement and support.

We also do not offer any formal consulting services. Companies known to offer such assistance can be found listed here, no endorsement implied.

Hosted SHSU Library icons for use on database/journal search interfaces & platforms:

• https://library.shsu.edu/images/fbprofile-horiz-med.jpg (234*60 pixel image)
• 
   
• 
   
• 
   
• SH-branded LinkSource icon 

Open URL Base:  http://linksource.ebsco.com/linking.aspx