OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

> Well, the problem is not bad application and bad user, but 
> good user and bad application. A user should trust the 
> interface in which she enters her credentials. And a user 
> cannot trust a random application.

My point is that if you have an application running on the
system you *have* to trust it to be a good application unless
you have some trusted environment that prevents the
application from interfering with or simulating your credential
prompt.  Such trusted environments do not appear in most
application environments.

Moving credential collection from within an application to a 
separate browser window does *NOT* add any realistic amount
of trust or security as the user doesn't KNOW or have a way
to prove, that it is really a browser window vs a window 
displayed by the application.

The key concept being that if I can get an application onto
your computer,  I can do pretty much anything (even taking
over the keyboard).  So I question the statement that an 
application isn't trusted and I think that you are creating
a lot of work that don't add real security or trust value
to the overal equation.

> > That said, the probably easiest thing to do would be for your 
> > application to act as a local web server and do an authen 
> request to 
> > the IdP with a response going to 
> localhost:theportyourlistening to.  
> > Then your client could just act as an SP speaking to the 
> IdP through 
> > the browser SSO profile.
> I do not fully understand your suggestion. Are you talking 
> about "webscraping" a login service. That's not a "real" solution.

I'm not talking about webscraping.  I'm talking about having your
application act as an SP making an authnrequest to the IdP.  You
can do this locally.  This SP would be at the address "localhost:port"
so that the idP could redirect the browser back to the application
with the authnresponse.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]