RE: [saml-dev] Non-web client authentication

["Cahill, Conor P" <conor.p.cahill@intel.com>]

> As an architecture designer I have problems with designing a 
> system where the flow must go through a third party 
> application. If I was an IdP I would probably not join the 
> federation if the credentials of my users MUST flow through 
> random, third party applications. If they went directly to me 
> through a browser window I would be OK with it. Why?

I will still reiterate my point.  You (as the IdP) and your
customer have *no* way of KNOWing that you are, in fact,
talking to a browser (whether or not you consider a browser
written by someone else to be a third party application).

I can easily write an application from scratch, or 
perhaps using libCurl or libwww, which to your IdP will
look, act, and feel like a browser.   


> 	1) Because if a bad application wants to get the 
> credentials it have to make an effort to get them, and 
> directly attack the architecture.  

This isn't any form of a significant effort (at least nothing
above the appliction writing code to talk to your IdP).  Off
the shelf libraries make this very simple.

> As an IdP I would say that this is the user's responsibility 
> that this do not happen. Bad applications that do open fake 
> web browser windows are more likely to be discovered than 
> those that does not. If the credential handling is done via 
> third party application, then I think the IdP should feel 
> abit responsible for how the application handles the 
> credentials. And it is impossible to be responsible for unknown code.

I think you have this issue regardless of this argument.  You,
as an IdP, have to realize, document, and risk assess, the problem
of a bad client running in your customer's environment.  What you
are proposing here does nothing to change that risk and just adds
more work to both the user and to the "good" application developer.

> 	2) One of many goals of federated ID systems is that 
> the user will get one single login interface that is visually 
> identical and can be trusted. If third party applications 
> should be allowed to display username/password widgets, it is 
> a way of saying: "You can enter your credentials wherever you 
> see a username/password dialog".

I haven't seen "on single login interface" as a goal in any
system as you can't do that and people involved in the specifications
recognize that there's nothing one party can do that another party
can't visually represent -- hence a good part of the success of
phishers is the fact that they can visually represent the contents
of the real site.

> 	3) There is alot of good applications that handle 
> credentials bad.  

This happens whether you're talking about a browser or 
talking about an application.  Again, I think the solution
for you would be to document how such work should be done for
"good" clients that want to work with your infrastructure.


> 	4) There is no way (that I know of) to restrict certain 
> applications for beeing allowed to perform authentication 
> against the IdP, while others are permitted.

This is exactly the point I have been making.  You can't
validate the clients that are talking to you, nor whether
or not they are a browser on your approved list or some
other browser.  

At best, you could issue a copyrighted token to "approved"
clients that is part of the authentication process.  And 
this would only give you some grounds for legally going 
after non-approved parties using said tokens.
 
> I know we cannot guearantee "real security" when dealing with 
> applications on client computers. But, my arguments above still holds.

It's not just "real security" it's anything that's even marginally
better than just working with the unapproved client.  If you think
you are getting something even marginally better, I think you 
misunderstand the ease of the attacks and the lack of ability of
the IdP to control in any way what goes on on the client.

Conor