The building blocks of Shibboleth Authenticated EZProxy Access.

Basic EZProxy Access Flow

This first diagram shows the decision flow for a resource being accessed though a commonly configured EZProxy Server. The path we are most interested in is when the resource is finally delivered through the EZProxy server to an authenticated user. The path we are interested in is highlighted in red in the diagram.

IPAuth Access via EZProxy and Shibboleth

The following three diagrams show different possible variations of the path highlighted in red above. The differences in the diagrams depend on the state of the EZProxy server and the Shibboleth Single-Sign-On(SSO) state.

In this diagram the user is starting fresh and a complete authentication is necessary.

In this diagram the user has previously established an SSO session with the Shibboleth server. Although authentication is requested from the Shib server the user is not prompted for credentials as they have an SSO session.

In this diagram the user has already established an EZProxy session. The EZProxy session is sufficient to authorize the user's access so no authentication request is made of the Shib server.

Through this series of diagrams you can see the progressive increase in access efficiency by using statefull access control.

A Real Life Example

In this diagram we see a common resource access pattern using an OpenURL Resolver. We see that the 'authenticate and authorize' flow is accessed twice in this example. Note that the second time the flow is invoked we can reasonably expect it to be handled within the EZProxy session and thus have very little impact on the overall life-cycle of the transaction.