RE: [liberty-dev] Identity Federation

To <>
From <>
Date Tue, 20 Jul 2004 16:53:57 -0400

From: john kemp []
Sent: Tuesday, July 20, 2004 4:23 PM

Hi Martin,

The ability of an IdP to send a (so-called) unsolicited AuthnResponse  
is closely linked to another practice - that of "bulk federation" -  
where an IdP already has business agreements with the SPs in its circle  
of trust such that federations can be set up by prior arrangement - ie.  
before any AuthnRequest/Response gets sent. This would result in each  
SP already maintaining at least a NameID, if not a full account for  
each user at the SPs site.

So, it is the case that in sending an unsolicited AuthnResponse, the  
IdP can reasonably expect that federation will occur (or not) according  
to the out-of-band agreement between the IdP and the SP(s) or the IdP  
should not be sending an unsolicited AuthnResponse. Of course, the SP  
is still technically able to just ignore the AuthnResponse if they  
wish, and that's a matter that would be resolved by their agreement  
with the IdP.

Typically in these cases, the user's consent to this bulk federation  
will also have been acquired prior to the sending of the AuthnResponse.

Does that answer your question?


- Jo

On Jul 20, 2004, at 3:38 PM, <> wrote:

> From: Mari Kemann []
> Sent: Monday, July 19, 2004 9:10 PM
> Hi folks,
> Currently I am dealing with the Liberty ID-FF version 1.2 and met a  
> problem I could not resolve yet. I went through the Liberty  
> specification again and again but so far I could not resolve my  
> problem.
> According to “Liberty ID-FF Bindings and Profiles Specifications” (p.  
> 18 –  3.2 Single Sign-On and Federation Profiles)  a Liberty IdP may  
> initiate the Single Sign-On and Federation Profile by unilaterally  
> creating a <lib:AuthnResponse> or artifact. In this case the identity  
> provider generates an authentication response that must be generated  
> as if the identity provider has received an authentication request  
> with certain minimal content. [See Liberty ID-FF Protocols and Schema  
> Specification p.20 – Processing Rules]
> Included in this minimal content is “any”  as value for the attribute  
> <NameIDPolicy>.
> In Liberty ID-FF Protocols and Schema Specification (p. 20 –  
> Processing Rules) is defined how to proceed in this case.
> If <NameIDPolicy> is any, then the rules above for the values of  
> federated and onetime MUST be followed, in that order. Thus, a new  
> federation may be created, an existing federation used, or a temporary  
> identifier generated.
> The rule for federated:
> If <NameIDPolicy>is federated, and if the Principal consents, then the  
> identity provider MAY federate the Principal’s identity with the  
> requestinf provider (or the affiliation group of <AffiliationID> is  
> present). If the identity provider already has a previous federation  
> on record for the Principal’s identity at the requesting provider or  
> affiliation group (such as when a provider previously issued a  
> <FederationTerminationNotification> which was not received by the  
> identity provider), then the identity provider SHOULD treat the  
> request as if <NameIDPolicy> were none.
> Now imagine the following case.
> A principal is visiting his identity provider’s website. After  
> authentication the user is provided with a choice of links which point  
> to the other members of the same Liberty circle of trust. The user  
> chooses to click on a link that is pointing to a service provider  
> where the user has another local identity. Both identities are not  
> federated.
> Every time a user clicks on one of these links the identity provider  
> initiates a Single Sign-On and Federation profile with the requested  
> service provider. It asks the user to allow identity federation and in  
> our case the user might give his/her consent.
> The created Liberty authentication response is created following the  
> rules mentioned above.
> Because there is no previous federation the identity provider  
> federates the user’s local identity with the service provider. The  
> response is constructed as described in Liberty ID-FF Protocols and  
> Schema (p. 14 – 3.2.2 Response).
> … the Format attribute MUST be urn:liberty:iff:nameid:federated.
> Together with this authentication response the user is directed to the  
> service provider. The usually the service provider would authenticate  
> the user and ask him/her for the consent to federate identities.
> My question is what happens if the service provider cannot federate  
> identities on its side. Either because the user does not have a valid  
> identity at the service provider or the user denies consents.
> The identity provider assumes an identity federation and the service  
> provider not. Does the service provider merely ignore the identity  
> federation on the identity provider’s side or is there a way to inform  
> the identity provider of the failed identity federation attempt.
> Cheers
> Mari

If you would like to unsubscribe from this list, please click on the URL 

The Liberty Alliance liberty-dev mail list archive can be viewed at the 
following URL:

Partial thread listing:

RE: [liberty-dev] Identity Federation(continued)
 dgc03052 (07/20/2004)
[liberty-dev] Need Cialis or other drugs – Purchase here online, (Chi Choi)
[liberty-dev] RE:awmlubk,UPTD – Major Trading Alert!!!! Our last Stock pick up 140%, (Rene )
Possible follow-ups
 MRS. PATRICA KOVAC (06/27/2004)


Please enter your comment!
Please enter your name here