RE: [security-services] question on MNI request for SP Lite/IdP Lite

From
ARI KERMAIER <>
Date
2009-03-25T20:41:16+00:00
ID
59b76a59-7bdf-4744-9555-b05d6f4e0cf4@default
Thread
RE: [security-services] question on MNI request for SP Lite/IdP Lite
Replies inline.

::Ari

  
-----Original Message-----
From: Kyle Meadors 
  [mailto:]
Sent: Wednesday, March 25, 2009 
  12:30 PM
To: 
  
Subject: [security-services] 
  question on MNI request for SP Lite/IdP Lite

  

  
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