For this year’s Liberty SAML IOP
event, we are adding a new error test case for SP Lite and IdP Lite
applications. Per the SAML conformance specification, SP Lite and IdP Lite
MUST NOT support Name ID management messaging and functionality. As some of
the vendor products allow their applications to be switched from SP to SP Lite
mode (same with IdP and IdP Lite), we need to fully test this “switch” and
verify they are properly acting in the SP Lite/IdP Lite
mode.
To do
this, we are expanding the error test tool. Once the ETT has established a SSO
with the SP Lite/IdP Lite with a persistent name ID, we plan on generating a
MNIRequest attempting to change the name ID. I have two questions which I
would like feedback from SSTC on…
[Ari Kermaier] What business does a Lite
implementation have using persistent NameIDs? My (admittedly
dim) recollection of the origins of this conformance mode is that it
stemmed from the concern of some SP implementers that they could not be
conformant unless they had account linking data storage that would persist
from one user session to the next. It seems to me, that the idea of a Lite
implementation is inconsistent with the persistent NameID processing rules,
and that differentiating based on support for MNI is really just a proxy for
differentiating based on persistence.
1. When a
SP Lite/IdP Lite receives a MNIRequest, what should be their proper response?
Ignore the request? Generate an error <Status> response? Either is
acceptable?
[Ari
Kermaier] There should be no MNI service endpoint to contact for an
implementation that doesn't support MNI. On the other hand, if the real
requirement is that the provider does not support persistent NameIDs, then the
MNI response should contain an error Status.
2. After generating the
MNIRequest, I planned on verifying the SP Lite/IdP Lite did not accept the
name ID change by sending a LogoutRequest using the new name ID from the
MNIRequest message and looking for the error <Status> response that the
SP Lite/IdP Lite does not recognize the principal. Then, send the
LogoutRequest using the original name ID from the Response message and
verifying principal is successfully logged out. Does this sound like a
reasonable test scenario?
Thanks.
Kyle
Meadors
Drummond Group
Inc.
Principal, Test
Process
(w)
615-212-0826
(c)
817-709-1627
kyle@drummondgroup.com