WELCOME TO THE IDP3 WEBINAR

We are just waiting for everyone to

login and you will be starting shortly

SHIBBOLETH IDENTITY PROVIDER- V3

Overview

An informative, plain speaking webinar on what is new in shibboleth IdP version 3, how to upgrade your IdP using the AAF installer and the Next Generation AAF project.

MEET THE SPEAKERS

Terry Smith – Technical Manager Australian Access Federation (AAF)

Terry is responsible for the ongoing operation of the federation and for providing support and training activities to the AAF subscriber community.

Vladimir Mencl – Senior Software Engineer at REANNZ (Tuakiri NZ)

Vlad is responsible for maintaining and developing the core Tuakiri services, as well as assisting candidate service providers with integration into Tuakiri. Tuakiri is New Zealand’s Access Federation.

HOW TO INTERACT WITH US DURING THE WEBINAR

During the session all attendees will be muted

To ask a question, enter it into chat

There will be time for Q&A at the end

The session will be recorded and made available after the webinar

1. What is new in Shibboleth IdP V3?

2. Shibboleth IdP v2 to v3 upgrade path

3. What are the concerns for Service Providers and Publishers regarding Shibboleth IdPv3?

4. Shibboleth IdPv3 Clustering

5. The Next Generation AAF project

WHAT WE ARE GOING TO COVER TODAY?

IdP V2 END OF LIFE?

All security bugs and severe non-security bugs addressed until Dec 31, 2015.

E.g. Any security bug and bugs preventing the IdP from running on supported platforms

Moderate security bugs addressed until Feb 29, 2016

E.g. Authenticated denial of service issues

Important security bugs addressed until May 31, 2016

E.g. Unauthenticated denial of service issues

Critical security bugs addressed until July 31, 2016

E.g. Remote exploits or data exposure issues

WHAT IS NEW IN SHIBBOLETH IdP V3?

Attribute release consent

Terms of use (no one use?)

Improved authentication system

SPNEGO – SSO from the desktop to the web

ECP support out of the box if password auth used

Client side storage

Cookies

HTML 5 local storage in next release

On the fly editing of login/logout pages etc.

WHAT IS NEW IN SHIBBOLETH IdP V3? Flexible configuration

Improved update process

Improved admin features such as: resolver tests and reloading services

Easier to integrate with non standard vendor requirements

Improved logout support

CAS protocol support built-in

Simplified clustering

Easier for developers to write new features

AAF – New version of the Shared Token generator plugin LDAP Support has been removed

IdP3

UPGRADE RECOMMENDATIONS

Do not attempt an in-place upgrade

Create a new server for IdP v3

Use an operating system with long term support (e.g. RHEL 7, CentOS 7)

Java 8 recommended (Java 7 will work but it is EOL)

Jetty 9.2/9.3 recommended now, (Tomcat is still an option)

Don’t use packaged versions of Jetty or Tomcat

Keep Endpoint URLs stay the same (minimizes changes metadata)

Use entry in local /etc/hosts when testing

Fast rollback if required

Use the AAF IdP3 installer

UPGRADE RECOMMENDATIONS

Attribute scripts will need to be updated if using Java 8 (change of scripting engine), if using 7 then scripts will work out of the box

Cleaner to use native v3 config files:

some elements are just ignored, making the configuration files confusing

as the deprecated methods may be removed at any time

you can use the new property replacement feature for config files

user consent does not work in legacy mode

Only after thorough tests replace the current IdPv2 instance with the new IdPv3 instance

test against the AAF federation test service provider

do it on your test IdP first

Note: If you don't have a test IdP server, set up a new test server or clone your current production server to make a new test server

UPGRADE METHODS

OPTION 1(Highly Recommended)

Install IdP v3 using the AAF installer as if it is a new install then modify

AAF Installer quick to build working IdP

Some work required to ensure correct IdPv3 native configuration files are setup to match v2 configuration

Test

Go Live!

UPGRADE METHODS

OPTION 2 (Not Recommended)

Let the Shibboleth installer upgrade your existing IdPv2 configuration then convert to native

Enables legacy mode to utilise existing config files to get you up and running fast (see this as a temporary stage only)

Resolver script changes still likely if Java 8 is used

Convert relying party, metadata providers, attribute resolver etc to native IdP v3 files afterwards

Disable legacy mode

Test

Go Live

SERVICE PROVIDER CONCERNS

IdPv3 is backwards compatible with IdPv2, everything should just work

Service Providers still using SAML 1 should consider moving to SAML 2

Service Providers using outdated software that only supports insecure encryption algorithms should be upgraded

Service Providers must ensure they fail gracefully if an attribute is not present

PERSISTENT ID FORMAT CHANGES

Historically, Shibboleth (IdPv2) deployments used eduPersonTargetedID as persistent, opaque, targeted user identifier

It should really be SAML2 Persistent NameID – same thing expressed with a different SAML element

Both are calculated as a hash of idpId, spId, userId, salt … but use a different implementation that yields different hash values

Both can use a database for storage – and share the data and use the same values

We strongly recommend rolling out Persistent NameID with IdP V3 (eduPersonTargetedID deprecated in IdP V3)

IdPv2 with EPTID+DB can migrate transparently

IdPv2 with EPTID computed on the fly SHOULD switch to a DB setup now for a smooth migration – start populating the DB with values in use

Otherwise, users would get a new identity at the target service…

BENEFITS No Single Point of Failure

Upgrade one node without affecting access to resources

Better resource utilisation

WHATS NEW? Memcache support built in

Cookies now the default for session storage allowing Active / Active setups to just work (SAML2 deployments only)

SHIBBOLETH IDPV3 CLUSTERING

ALSO REQUIRES Clustered Database

HA Load balancer / application switch

HA Directory service (LDAP / AD)

SHIBBOLETH IDPV3 CLUSTERING

WITHOUT MEMCACHE (not using cookies for session storage)

WITH MEMCACHE

1. User Logs In

2. IdP1 fails

3. User is directed to IdP2

4. User has to login again

1. User Logs In

2. IdP 1 fails

3. User is directed to IdP2

4. User does not need to login again as IdP2 is aware of the session created on IdP1

Users

IdP

1

IdP

2

Memcache Shared Session

THE NEXT GEN AAF PROJECT

Activity 1 - Government Requirements for AAF Participation

Activity 2 - Next Generation Software Extensions

Next generation Discovery Service

International connectivity

Enhanced user experience

Additional support for ECP

Improved federation utilisation statistics

non-web service option (RADIUS) as part of the trust fabric

Activity 3 - SaaS Identity Provider

REFERENCES

AAF IdP V3 Installer

Tuakiri guide: Installing a Shibboleth 3.x IdP

Shibboleth guide: Upgrading from V2

Shibboleth guide: Identity Provider 3

The Next Generation AAF project overview

WEBINARS In 2016 the AAF will be running a number of technical webinars, so keep an eye out for future invitations.

Q&A responses

1. Does that mean I can't pass through a pre-generated token, which I have stored in LDAP? The LDAP plugin option has been removed from IdP3. Previously, the plugin was able to populate the LDAP directory with a shared Token generated by the IdP. If you are pre-generating the token, you just need to change the configurations to point to the LDAP directory rather than the plugin. You don’t have a need of the plugin at all. 2. ADFS3 + IDP3 - has anyone got this documentation yet? We don’t recommend using the ADFS3 for the following reasons:

• No consent for attribute release

• No support for eduGAIN

• No ECP support

However, you can put an IdP in front of an ADFS system and there won’t be any integration problem as it will be directly talking to LDAP not SAML. The LDAP configuration is pretty much unchanged if upgrading from V2 to V3. You may have to do some configuration changes if the java version changes. The UK federation has developed a bridge between ADFS and Shibboleth IdP. It allows you to login to one that will log you into another automatically. It doesn’t matter which one you login to first, it will automatically log you in at the same time. We are still trying to get more information on what that means for us in the federation and what is involved in setting that up. When we have more information we will make it available for all.

Q&A responses

3. Does the installer migrate the current db with values to the new version? There will be a migration process where you need to export the current databases and then import them into the new IdP server. There will be an upgrade guide available on how to carry out the configuration. While the migration guide would support migration of auEduPersonSharedToken and PersistentID values, other aspects of the database (namely, attribute release consent already granted) would be dropped, as the data structures have changed substantially. 4. How does the clustering work when CAS sits in front of IdP when it comes to Memcache etc.? We need to investigate this further. Once we have enough information we will make it available for you. 5. In V3, could you simply present eduPersonTargetedID as a value derived from (mirroring) the PersistentNameID?

- i.e. carry on legacy presentation of eduPersonTargetedID indefinitely

We have done a review within the AAF federation about the service providers using the eduPersonTagededID and PersiistentID together, because those service providers will have potential issues. Two values will be presented as multiple values in the attributes. There are only 10 SPs identified using both the values currently. We strongly suggest you use the NameID rather than eduPersonTargetedID.

Q&A responses

6. Does the installer look after customizations done in Attribute Resolver? e.g. custom attributes etc.? The installer will create a basic configuration including all the important files like attribute resolver. Once you have completed the install, you can make changes to the configuration files and customise it to suit your environment. All modifiable configurations are located in the directory: /opt/shibboleth-idp-installer/repository/assets/<HOST_NAME> After you make each change, re-run the opt/shibboleth-idp-installer/repository/update_idp.sh 7. What is the real issue with using the packaged version of tomcat? The packaged tomcat version, puts files in different places and installs extra-unwanted files and it is also several versions behind it. With IdP3, we are moving away from tomcat and going with jetty. The Shibboleth project still supports tomcat 8. If you want to continue with tomcat, refer to Tuakiri documentation for IdP3 install manual that covers tomcat installation. Shibboleth do not officially support any packaged containers provided by OS vendors.