RE: [saml-dev] Authentication on IDP.

Title: Message

  

  
    
      
do we have 1 
      certificate for all the request at the IDP ? IMPORTANT: but then how the 
      IDP (and in the end the SP) distinguish which user is that request 
      from? 

I'm not sure 
what you're asking here.  The IdP always distinguishes the user at *its* 
system by the credentials provided by the user (and this sequence is 
out-of-scope for SAML).

Just to give an Example: 

 

User A access SPA.

SPA redirect to IDP asking for a Certificate based 
authentication.

IDP perform this but (unless I'm wrong) the certificate wouldn't contain 
any info specific to the user but mainly keys info.

in this case the IDP has to also identify the user in order to reply with 
a subject to the SP. I guess it would perform a Userid/password (basic 
auth)

authentication.

I guess this is reasonable to expect from the IDP.

 

Now What is the Auth context he is going to send back 
?  

    Certificate based authentication ?

    User Id/ password 
?

    or both ?

 

Giuseppe.

  

  
-----Original Message-----
From: Conor P. Cahill 
  [mailto:] 
Sent: 31 October 2005 
  16:43
To: Sarno, Giuseppe [MOP:GM15:EXCH]
Cc: 
  
Subject: Re: [saml-dev] Authentication 
  on IDP.

Giuseppe Sarno wrote on 10/31/2005, 11:22 
  AM: 
  

  
    
Hi, 
I'm trying to understand how the 
    IDP knows what credential to apply in case of authentication challenge in a 
    SSO scenario.

    
Pricipal seen as USER_A on SPA and USER_B on SPB 
    and USER_IDP on IDP 
    

    
SPA initiated: 
SPA redirect (for example) authrequest to IDP indicating that the 
    AuthContext_A AuthContext should be applied to the user.

    
Question 1:  
in 
    case Context_A = userId/password, what user Id should be used ? 
        The one known at the IDP (USER_IDP) (which means we can 
    only use the user identifier at the IDP for that circle of trust) 
    

    
        or (in case the ID has the knowledge) could actually use the USER_A 
    as known at SPA.
The IdP *always* authenticates the user using 
  it's own credentials (so USER_IDP in your example).  It is possible 
  (totally out of scope for SAML) for the IDP to have arrangements with other 
  providers (such that if USER_IDP was ,  the IdP would 
  "delegate" the authentication via some backchannel to mycompany.com's 
  authentication service), but the user is still logging in with an identity 
  that is valid at the IdP, regardless of where the IdP obtained the 
  credentials.

In a world without Federation, the USER_A, USER_B and 
  USER_IDP would all be the same value so that the IdP could send USER_IDP in 
  the assertion to SPA and SPA would be able to provide service.

In a 
  typical world with Federation, the IDP sends a relationship specific 
  identifier for the user (which, could also be a transient identifier,  
  but that usually means transient sessions at the SP).  So the IDP 
  validates USER_IDP and then sends nameID 123 to SPA (assuming that at some 
  point in the past USER_IDP was federated to that SP and the id 123 was 
  assigned to that relationship).

  
    

    
SPB Initiated 

    
Quetion 2: 
in case of Context_B = again where the IDP gets the certificate from 
    ?
Authentication contexts on an authnRequest are 
  statemetns from the SP to the IdP asking the IdP to perform a particular 
  action.   The action itself (i.e. how the IdP accomplishes the 
  necessary steps to achive that context) is totally between the user and the 
  IdP (although typically, when a Circle of Trust is setup the IDPs and SPs will 
  agree on the set of contexts supported -- another thing out of scope for 
  SAML).

So whatever the IdP uses to establish a context is between the 
  IdP and the user.  If the user needs a certificate, then the user must 
  have gotten that from the IdP at some point in the past.

  
    

    
      
        
do we have 1 certificate for all the request 
        at the IDP ? IMPORTANT: but then how the IDP (and in the end the SP) 
        distinguish which user is that request from? 
  
I'm not sure what you're asking here.  
  The IdP always distinguishes the user at *its* system by the credentials 
  provided by the user (and this sequence is out-of-scope for 
  SAML).

  
    
      
        

        
          
IMPORTANT: should the request in this case 
          also include a userid/passowrd request ? I guess from what I've seen 
          SAML cannot apply 2 Auth mechanisms at the same time (can it ?). which 
          means SPB would need to re-ask for authentication, but I don't know if 
          this would work. Any idea ? 

SAML allows the user to request a 
  list of contexts, a class, a class with a comparison (e.g. "stronger" than 
  username/password).  I don't believe more than one can be in effect for a 
  particular assertion (although you can define classes that are built by 
  combinations of other classes -- classes are fully extensible -- for example, 
  one could define a class that is username/password *plus* 
  one-time-password).

  
    
      
        
          

        
Does the IDP have different certificates per 
        SP? again the authrequest or MetaData seem not providing this 
        distinction. 
Out of scope for SAML.  an IdP could have 
  different certificates for every *request* if it wanted to and if it was able 
  to get those certificates defined to the point that they would be trusted by 
  the SP -- not that I am saying that this is reasonable or likely, just that 
  it's possible.

I think that in many cases the IdP will use a single 
  certificate across SPs, but that is an implementation decision for the IDP, 
  not a specification in 
SAML.

Conor