Child pages
  • ShibPlanning-AppAnalysis
Skip to end of metadata
Go to start of metadata

Shibboleth Planning: Analyze Your Application

Who Should Read: This document is written for technical staff looking to integrate their application with Shibboleth SP 1.3 or above.

Before you start installing/configuring the Shibboleth SP it is important that you think through and answer some questions.

This checklist should give you an idea whether you are ready to for integration/migration:

Will Shibboleth support all my needs?

Shibboleth provides Authentication, Web SSO and Attributes(Data). This should serve the needs of most applications on campus.
Contact IAMUCLA if you need additional services that Shibboleth does not yet provide, for example, Access Control/Authorization.

Is my platform supported?

For a list of all supported platforms visit the "Native Service Provider (SP)" section located here.
Please note you will need to run a web server, either Apache or IIS.

Do I have the resources to make the switch?

You will need to allocate sufficient Hardware, Software, Developer/System administrator, Help desk resources to complete the migration.

How long will it take to integrate my application with Shibboleth?

This may take anywhere from two weeks to a few months. It depends on many factors:

  1. Environment set up. Do you already have a web server (Apache or IIS) or you need to set up one?
  2. Knowledge of Xml, SSL certificates, Web servers.
  3. Special Run time environments like virtual hosting, desktop client, Load balancing/Failover.
  4. Application modification. At the very least you have to read the http headers or environment variables delivered by Shibboleth and move on with your business process.

What kind of change is required within my application?

If you are already using the ISIS authentication service:

  • Remove all the code that is ISIS related (ILS, IWS, ISIS Error handling etc.)
  • Read http headers or environment variables at the entry point of your application and move on with your application logic. You may store this data within your application in session or request scope.

If you are integrating a new application with Shibboleth:

  • Read http headers or environment variables at the entry point of your application and move on with your application logic.

How many of my applications will I migrate now?

If you have multiple applications start with the least critical one. Once you becomes familiar with Shibboleth and feel confident with the process, migrate the rest.

Will my application accept UCLA Logon?

Shibboleth supports the UCLA Logon ID ONLY (formerly known as Bruin On Line or BOL). This should be familiar if you used the ISIS Authentication service before.
Logon type should not concern applications since you only need to make sure user is authenticated and that user data is available. If you have a concern on this front, please contact the IAMUCLA team.

Which version of Shibboleth do I install?

If you are starting today we recommend v2.1. You may use v1.3 but then will need to upgrade at some point in the future, effectively creating extra work for yourself.

Have I allocated enough time to integrate my application with Shibboleth?

Give yourself enough time to install, configure, coordinate (with the IAMUCLA team), obtain data approval and test.

Will I be storing the data I obtain from Shibboleth?

User data delivered by Shibboleth may be subject to State, Federal and UCLA privacy policies. If you are storing the data, you have to protect the data and abide by the privacy laws. Request only the data you absolutely need for your application.

Do I have proper admin access to the server I am working on?

You need proper administrative access to the server for installing, configuring Shibboleth software. Web server (IIS or Apache) and Shibboleth services should have proper read/write permissions to file systems.

Who are my users?

Who is your user population? Are they students, faculty, staff, alumni, guests or a combination of one or more of these? Your user base will be one of the factors in determining how you obtain data, who approves data release etc.
Are all the users within UCLA or coming from other institutions? In a federated application you could have users coming from within UCLA or outside.

Can Shibboleth deliver all the data I need?

Think of all the data (name, email, department etc.) you need about the authenticated user. Shibboleth has a flexible data management mechanism and offers a wide range of data not previously available. The data store behind Shibboleth is the UCLA Enterprise Directory. You may still need to extract the data out of band or existing channels. For ex, Student Course enrollment information is not available via Shibboleth yet

Will the migration/integration affect my users in any way?

Can you make seamless transition without causing an outage or service/performance degradation? Ideally users should not notice the difference, other than few subtle browser redirects.
Either way involve your users early in the process and advise them of the coming change.

Who will user turn to for help when there is an error?

If the user experiences an error who would he/she contact first? You should be able to identify the location of error and display appropriate Help desk contact for immediate resolution.

Let's move on to Step 2

Planning Guide Topics

0. Get Started
1. Analyze your Application
2. Determine your Data Requirements
3. Register Your Application with IAMUCLA ShibPlanning-Registration
4. Join Shibboleth Support Community
5. Install and Configure Shibboleth