...
Test
...
IdPs
...
in
...
Metadata
...
The
...
first
...
IdP
...
an
...
organization
...
introduces
...
into
...
metadata
...
is
...
assumed
...
to
...
be
...
a
...
production
...
IdP.
...
Please
...
do
...
not
...
submit
...
temporary
...
IdP
...
metadata
...
with
...
the
...
intention
...
of
...
changing
...
it
...
later
...
on.
...
IdP
...
metadata
...
that
...
is
...
obviously
...
temporary
...
(e.g.,
...
metadata
...
that
...
contains
...
the
...
substring
...
"test"
...
in
...
names
...
and
...
locations)
...
will
...
not
...
be
...
approved.
...
As
...
a
...
matter
...
of
...
policy,
...
each
...
organization
...
is
...
allowed
...
one
...
IdP
...
entity
...
descriptor
...
in
...
metadata.
...
By
...
request,
...
a
...
second
...
IdP
...
in
...
metadata
...
may
...
be
...
purchased
...
for
...
an
...
extra
...
$1,000
...
per
...
year.
...
This
...
second
...
IdP
...
may
...
be
...
a
...
test
...
IdP.
...
That
...
said,
...
in
...
almost
...
all
...
cases,
...
it
...
is
...
neither
...
necessary
...
nor
...
advised
...
to
...
register
...
a
...
test
...
IdP
...
in
...
metadata.
| Info | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| =
|
|
|
| ||||||
| }
Test IdPs in InCommon metadata serve little or no purpose. Since test IdPs are indistinguishable from production IdPs to both relying parties and end users, the introduction of explicit test IdP metadata is strongly discouraged. {info} h3. A General Migration Strategy for IdPs The following migration strategy does *not* require test IdP metadata to be registered with InCommon: # *Optimize the production IdP*. Evaluate the use of [back-channel protocols|Back-channel SAML Protocols] on your production IdP with an eye towards eliminating unused protocols and endpoints. Phase out seldom-used protocols if possible. An optimally configured IdP will support SAML2 on the front channel only. # *Deploy a test IdP*. Configure this test IdP to be nearly identical to your production IdP (same entityID, same metadata sources, same attribute release policy, etc.). |
A General Migration Strategy for IdPs
The following migration strategy does not require test IdP metadata to be registered with InCommon:
- Optimize the production IdP. Evaluate the use of back-channel protocols on your production IdP with an eye towards eliminating unused protocols and endpoints. Phase out seldom-used protocols if possible. An optimally configured IdP will support SAML2 on the front channel only.
- Deploy a test IdP. Configure this test IdP to be nearly identical to your production IdP (same entityID, same metadata sources, same attribute release policy, etc.).
Wiki Markup {div:style=margin-top:1.5ex;}{note}Your test IdP should have _the same entityID_ as your production IdP so that the two are indistinguishable by relying parties (such that the two really are *one logical IdP*). Consequently, a single entity descriptor in metadata is sufficient to describe both IdPs. Any SP that consumes that metadata will interoperate with either your test IdP or your production IdP.{note}{div}
...
There
...
- are
...
- at
...
- least
...
- two
...
- deployment
...
- options:
...
- Deploy
...
- the
...
- test
...
- IdP
...
- on
...
- the
...
- same
...
- host
...
- .
...
- In
...
- this
...
- case,
...
- the
...
- endpoint
...
- locations
...
- of
...
- the
...
- test
...
- IdP
...
- will
...
- have
...
- the
...
- same
...
- hostname
...
- but
...
- a
...
- different
...
- path.
...
- This
...
- is
...
- perhaps
...
- the
...
- simplest
...
- option
...
- since
...
- then
...
- the
...
- production
...
- IdP
...
- and
...
- the
...
- test
...
- IdP
...
- can
...
- easily
...
- share
...
- the
...
- same
...
- signing
...
- key.
...
- (In
...
- this
...
- scenario,
...
- the
...
- test
...
- IdP
...
- is
...
- really
...
- an
...
- extension
...
- of
...
- the
...
- production
...
- IdP
...
- environment.)
...
- Deploy
...
- the
...
- test
...
- IdP
...
- on
...
- a
...
- different
...
- host
...
- .
...
- In
...
- this
...
- case,
...
- the
...
- endpoint
...
- locations
...
- will
...
- have
...
- a
...
- different
...
- hostname
...
- but
...
- the
...
- same
...
- path
...
- as
...
- the
...
- production
...
- IdP.
...
- One
...
- option
...
- is
...
- to
...
- copy
...
- the
...
- production
...
- signing
...
- key
...
- onto
...
- the
...
- new
...
- host
...
- (without
...
- exposing
...
- that
...
- key
...
- of
...
- course).
...
- Another
...
- option
...
- is
...
- to
...
- use
...
- a
...
- new
...
- signing
...
- key
...
- (which
...
- should
...
- be
...
- no
...
- less
...
- secure
...
- than
...
- the
...
- production
...
- signing
...
- key).
...
- The
...
- certificate
...
- corresponding
...
- to
...
- this
...
- new
...
- signing
...
- key
...
- may
...
- be
...
- added
...
- to
...
- the
...
- IdP's
...
- entity
...
- descriptor
...
- in
...
- metadata
...
- so
...
- that
...
- there
...
- are
...
- two
...
- certificates
...
- in
...
- metadata,
...
- one
...
- for
...
- the
...
- production
...
- IdP
...
- and
...
- one
...
- for
...
- the
...
- test
...
- IdP.
...
- Exercise
...
- the
...
- test
...
- IdP
...
- .
...
- There
...
- are
...
- at
...
- least
...
- two
...
- test
...
- scenarios
...
- depending
...
- on
...
- how
...
- the
...
- test
...
- IdP
...
- is
...
- deployed:
...
- Using
...
- IdP-initiated
...
- SSO
...
- on
...
- the
...
- test
...
- IdP,
...
- systematically
...
- push
...
- SAML2
...
- assertions
...
- to
...
- endpoints
...
- at
...
- select
...
- partner
...
- SPs.
...
- If
...
- the
...
- test
...
- IdP
...
- is
...
- deployed
...
- on
...
- a
...
- different
...
- host,
...
- map
...
- the
...
- IdP
...
- domain
...
- name
...
- (in
...
- metadata)
...
- to
...
- the
...
- IP
...
- address
...
- of
...
- the
...
- test
...
- IdP
...
- using
...
- /etc/hosts
...
- on
...
- a
...
- client
...
- machine.
...
- Using
...
- SP-initiated
...
- SSO,
...
- systematically
...
- test
...
- select
...
- partner
...
- SPs
...
- using
...
- the
...
- client
...
- machine.
...