RE: First contact

[Tim Moses <tim.moses@entrust.com>]

Title: First contact

Anders - I think the right place to address these issues, in the first instance, is in the Bindings working group.  I don't believe this group has a schedule for its next meeting.  But, I expect Prateek will organize one shortly.

 

My personal feeling (at the moment) is that the Pull model currently defined in the draft SAML Bindings specification satisfies the requirements, as stated in the Use Case and Requirements document.  But, if you can persuade the working group that your proposal is superior, taking into account performance, firewall-friendliness, trustworthiness, intellectual property, etc., then I am sure it would be possible to modify the draft.  I would not be in favour of standardizing two possible solutions.

 

Best regards.  Tim.

 

-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@telia.com]
Sent: Wednesday, August 01, 2001 2:49 AM
To: Tim Moses; 'OASIS Security Services group'
Subject: Re: First contact

Tim,

 

Slight return on a popular issue.

You claim that you are satisfied with the current browser profile but anyway claim that the Push model

due to inferiority, will not get popular, and in another posting claim that the Push model is "brain dead".

I don't see the point of standardizing a thing that is brain dead.  It would be nice if some other persons

would like to comment on this.  I.e. if a thing is technically "possible" but has built-in flaws that

have no good solutions, I think it should be outside of a standard in order to promote interoperability.

 

I have as you may have noted, not come to the same conclusions regarding the push model (my two

contributed documents fully address all your concerns) but that is another thing.

 

And the question remains: Should SAML really standardize things that are "brain dead"?

 

regards

Anders R

----- Original Message -----

From: Tim Moses

To: 'OASIS Security Services group'

Sent: Wednesday, July 25, 2001 23:51

Subject: First contact

Colleagues - I've given consideration to the "first contact" issue, and satisfied myself that the current browser profile satisfies the requirement.

For those interested in the details ...

Remember, the question is ... what will be the message flow if the subject first goes to a site that has protected content, rather than first going to an authentication site?

Push model

Browser                   Content site         Authentication site
1 <----------- redirect----------
2 -------------redirect----------------------------------->
3 <-------------------------authenticate------------------>
4                                  <-------assertion-------
5                                  --------reference------>
6 <-----------------------------------redirect(reference)--
7 --------redirect(reference)--->

Pull model
Browser                   Content site         Authentication site
1 <----------- redirect-------------
2 -------------redirect----------------------------------->
3 <-------------------------authenticate------------------>
4 <-----------------------------------redirect(reference)--
5 --------redirect(reference)------>
6                                  --------reference------>
7                                  <--------assertion------

The Push model leaves questions like ...
How does the Authentication site know where to send the assertion?
How does the Authentication site know what attributes to include in the assertion?
Furthermore, the authentication thread is occupied waiting for the reference to return from the Content site.

This might all just mean that the Push model becomes less popular than the Pull model in this situation.

In both cases, the Content site has no opportunity to indicate its authentication requirements (one or two factor, for instance).  But, perhaps, each Authentication site URL should be dedicated to a single authentication policy.  Then the Content site chooses the policy by redirecting the browser to the appropriate URL.

Step 6 in the Pull model is a SAML request for one or more assertions.  The request must be able to carry the reference extracted from the artifact in the redirection steps (4 and 5) as well as the list of requested attributes.  So, I'll be checking the schema proposals to ensure that this is possible.

Best regards.  Tim.

-------------------------------------------------------------------
Tim Moses
Tel: 613.270.3183