Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The key to this approach is emulation of a 2.x IdP by your existing 1.3 IdP. The 2.x IdP cannot easily be made to look as if it were a 1.3 IdP. I would not say it's impossible (frankly I don't know), but I would say that it's simpler to go in the reverse direction. In most cases, a 1.3 IdP can be made to operate with the same default/accepted behavior as the new software, at least from the point of view of an SP. In particular, its paths and locations for responding to requests can be altered relatively easily to match the 2.x software.

Tip

Part of emulation naturally usually also includes using the same entityID and credentials on both the old and new installations. From an external point of view, they are identical except for the endpoints. If desired, it is possible to change the credentials, since the metadata that contains the new endpoints can contain the new credentials as well. But since there are often SP configurations and links/bookmarks that reference the IdP's entityID, it is usually a terrible idea to change your IdP's entityID. I would also note that changing the entityID can affect the values of certain attributes, such as eduPersonTargetedID, as well.

Changing Endpoints

...

The key is that the thoroughness of the testing process is really up to you because you now control the exact timing and duration of any switchover. In fact, you may well wish to slip the 2.x IdP into operation for short periods to evaluate the results before you make a full-time change. You don't need to tell anybody you're doing this (other than informationallyas a point of information), and you can stop the test any time you need to , because the metadata is the same for the two IdPs.

...

Many sites use (or attempt to use) this strategy for migrating their IdP from one major version to another (e.g., from Shib 1Shib 1.3 to Shib 2Shib 2.x):

  • Set up a new installation on a new server with a new production hostname, a new entityID, certificate, etc.;
  • Test the new IdP using SPs set up for the purpose, or other nearby SPs that can be convinced to try it;
  • Once it's tested, update the metadata in federations you participate in to point to the new IdP;
  • Fix whatever broke.

...

In general you have no explicit control over when the updated metadata will get installed by any particular SP. It may take days. You cannot revert your metadata to quickly move back to the old IdP , because it will take time for that backed out change to propagate to federation SPs also. It's failure by water torture. There may even be hopeless SPs that aren't updating their metadata regularly at all, though frankly they're not worth caring about. (If they don't care if it works, you shouldn't.)

...

Note also that what you might like in this situation is to register the new IdP in your federation(s) in order to test it with federation SPs. This doesn't work very well in practice, even if the federation supports it. There may be problems for users knowing which IdP to use. High-volume production SPs will be unlikely to want to test with your IdP. For SPs that implement their own discovery mechanism, you may not have any control over which IdP they use. You also won't have access to their logs, which you need to diagnose problems when testing. So testing is much more likely to be successful when handled outside of the federation.

...