Penn Shibboleth


ISC Networking & Telecommunications


Penn WebLogin
	Help

	Shibboleth Reference
	Main Page
	Service Provider Information
	InCommon Process
	Shibboleth Setup and Configuration
	SP Validation

	Quick Links
	SP Registration Form (Requires Pennkey Login)
	InCommon Registration Form
	Known Issues
	Intake Process Flowchart
	Road Map
	FAQs

ISC Networking & Telecommunications Shibboleth Service

The below is provided as a reference for application owners considering using Penn’s campus directory services as the authentication source. This Authentication Option Matrix contains at-a-glance information on the possibilities available for authentication in your application. Using campus directory services as the base for authentication offers the following benefits:

The identity provider manages security and privacy for its users.
The service provider is only responsible for authorization to its application.
Users need to use and maintain fewer credentials.
No need to provision accounts on the resource.

ISC offers multiple ways to provide authentication for an application. The checklist and table below are a reference to help you and ISC assess which solution is best for your situation.

Guiding Checklist

Local Authentication

Your application has relatively few users, or a heterogeneous set of users not defined elsewhere.
Your application is intended for a relatively small audience, such as a lab, office or department.
Your application requires independent authentication or for business reasons must not participate in single sign-on.

WebLogin

Your application is hosted internal to Penn.
You expect to offer an application, such as finance or personal records software, to a large but Penn-internal user base.
Your application has a strong logout security requirement.

InCommon

Your application (e.g. a library catalogue system) is open to a larger academic and research community. Future members of InCommon will not need to be added individually. (Registering an application with InCommon is not cost-free for ISC)

Non-InCommon Federation

Your application is not open to the broader academic community but hosted externally, such as an SaaS project management application. Additional identity providers will need to be added by your organization.

Authentication Option Matrix

	Local Authentication	WebLogin/CoSign	InCommon	Non-InCommon Federation
What it is	The application performs authentication and authorization independently. The application maintains its own database of users and does not participate in Single Sign-On at all.	WebLogin is an open source, single sign on (SSO), cookie based, web authentication service; it provides basic PennKey based web authentication.	The InCommon Federation is a trust network which provides application single sign-on across domain through independently vetted identity and service providers. Ultimately, this uses Cosign as the identity provider.	Federation is a trust relationship between an identity provider and a service provider that offers web SSO. It uses Cosign as the identity provider and provides authentication through campus directory services.
Additional Information	--	http://www.upenn.edu/computing/weblogin/	http://www.incommon.org/	http://shibboleth.internet2.edu/
End User Experience	User must log in separate from other applications.	User signs in once and is given access to protected applications.	User signs in once and is given access to protected applications.	User signs in once and is given access to protected applications.
Community Adoption	Common mode of authentication for many applications.	Originally developed by the University of Michigan and deployed in a handful of higher education institutions.	Deployed by a broad academically-centered community. Employs industry standardized protocol for trust relationship.	Employs industry standardized protocol for trust relationship.
Ease of Deployment	Most applications are already configured for local authentication.	Architecturally similar to previous central authentication systems; relatively easy deployment with provided documentation.	More complex implementation for application developers.	More complex implementation for application developers.
Authorization Considerations	Authorization performed locally after authentication.	No privacy-preserving authentication. Extra step required for authorization.	Enables informed authorization decisions while preserving privacy.	Enables informed authorization decisions while preserving privacy.
Federation Support	No	No	Yes	Yes

Service Alerts



Information Systems and Computing University of Pennsylvania Comments & Questions