IdP v3 Relying Party Configuration

[Kevin Ratcliffe]

Surely the v2 attribute-resolver and attribute-filter IS the v3 attribute-resolver and attribute-filter. Well that's how I've been looking at it.

Kevin Ratcliffe
Network & IT Systems Support
Bolton Sixth Form College
T: 01204 846215
E: kratcliffe at bolton-sfc.ac.uk
W: www.bolton-sfc.ac.uk
Save Paper. Please consider the environment before printing.

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: 04 February 2016 15:54
To: Shib Users <users at shibboleth.net>
Subject: RE: IdP v3 Relying Party Configuration

> I consider our migration a success.
> We only use a handful of SPs with no complex requirements.

A lot of deployers aren't in that situation though. They have SPs that they may not even specifically understand are using their service unless they look at logs.

> Office 365 is a new relying party for us and the only documentation I 
> can find is for IdPv2.

Documentation should never be about an IdP product at all. That's doomed to fail. The only way the integrations can be documented effectively is by expressing the technical requirements individually so that the products can provide help in how to configure those requirements. I think, now that I mention it, one of InCommon's interop WG's tasks might be to come up with a template for that.

> Shibboleth, for me is quite complex, I don't do Java, servlet 
> containers and rarely touch XML so having a mashup of
> v2 and v3 configuration files would be a real headache.

You already have that mashup. The resolver and filter config are carried over, so it's not as though it's not a mix of old and new. And one of the really simple breaking changes comes from transplanting resolver files and not realizing that some of the syntax in the new default files results in different behavior on the wire that breaks some SPs. I was comfortable with how it ended up precisely because it never occurred to me anybody would willingly rewrite their resolver from scratch right from the start.
 
> That's why I opted for
> a fresh slate. Could I enquire how migration 'breaks' SPs?

When you have hundreds of SPs, some of which you don't even know you have, you can't possibly test every one of them. So you have to understand really deeply what your configuration is doing, the defaults in place, what changes when you make particular choices, etc. There are material changes and some of those changes happen specifically due to starting with the new files and trying to transplant only some of the settings over. It's pretty much a given that you'll miss something, or not understand the implications of changing something.

The worst example I know of is that some people have managed to generate and issue different persistent ID values after upgrading.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

This email has been scanned by BSFC and seems to be OK