View
939
Download
5
Category
Preview:
Citation preview
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.
Recommended