[Fusionforge-general] Auth* and APIs - Was: Re: SOAP Api change proposition

[Christian Bayle]

On 26/03/2010 14:44, Olivier Berger wrote:
> Hi.
>
> (Changing the Subject: to try and separate from the SOAP-specific
> discussion)
>
> Sorry in advance for some void discussions. More concrete questions at
> the end.
>
> Le jeudi 25 mars 2010 à 22:35 +0100, Christian Bayle a écrit :
>    
>> Hi
>>      
>>>> There is different solutions. The most used is HTTP Basic Auth.
>>>>
>>>>          
>>> OK, but this requires some user of the forge whose password is given to
>>> the client tool executing the invocation... with security risks at
>>> stake. This might work in some contexts but not in others (and also
>>> requires one to be able to protect the SOAP endpoint with some Apache
>>> configuration, which is less manageable as something handled by the PHP
>>> code).
>>>
>>>
>>>        
>> I rather disagree as there are so many way of handling auth
>> with php
>>      
> Examples ? ... please try and be specific in your contributions, so we
> can try and understand exactly your point ;)
>
>    
Just an example, there is no single way of generating a session cookie, 
almost every php webapp has it's own.
So if you want to share the same cookie between webapp, you have to 
reimplement in each webapp a single way of generating/checking a cookie.
And if fact the only thing the app needs is a user id you can get easily 
from webserver env.
>> that letting auth external is often a better idea.
>>      
> OK. That's true in a sense, but I may have missed to add a point that
> may explain why I prefer things done at the application level :
> things like apache configuration (access rights, rewrite rules, etc.)
> are hard to include in packaging (Debian for instance), from my own
> experience with packaging web apps.
>
>    
humm quite strange, a simple .htaccess provide basic auth control
I dont see your point about rewrite rules, exemples welcome.
access rights has to be managed separatly, first i prefer to forget 
about it,
until we are ok about authentication.

> I believe doing things at the PHP/app level leads to less dependency on
> the context in which the application is deployed, so that should be more
> flexible in the end, even though more difficult to implement, than
> saying : go configure something in Apache (or Unix). It will be more
> secure too, as no one will have forgotten the bullet in the HOWTO
> explaining how to secure the app by adding lots of configuration items
> in apache.conf ;)
>
>    
If the context is that you don't control the apache config because you 
are hosted
may be, but a forge is not a simple webapp.
> For instance I tend to think about web apps as things that should be
> easy to use on hosted providers, where you may not be able to change the
> underlying configuration like PHP settings or Apache config, and also as
> apps that you can apt-get install and that will work out of the box.
>
>    
A webapp  is especially easy to use if it doesn't make any choice on how 
auth is managed.
only one assumption should be done on the webapp, there is a way to get 
a user id
before the page starts loading, in case you choose to rely on simple 
.htaccess
in php you can get the user by a simple
$user=$_SERVER|'REMOTE_USER'];
this also allow you to use your custom auth function in php
$user=mysupercustomfunc();

> It happens that you never can really plan how the system bellow the app
> is configured, and that to make it worse there's no real support for web
> server configuration for packaging scripts.
>
> Of course, I understand that this is probably not common approach for
> people used to deploy the forge on a dedicated system.
>
>    
ditto
>> Just trying to use mylyn with various forge let you see it would be much
>> simpler
>> with apache auth.
>>      
> Uh... can you explain ?
>
>    
mylyn with basic auth works, you have to re-implement session as it's 
managed on each app
you want to connect to. This made I could only use mylyn readonly on 
some forge, because
probably a subtil different way of handling cookies.

>> For the security problem http has many standart solutions, very well
>> handled.
>>      
> Sure but which require a lot of knowledge from the (sys/apache)-admin as
> if handled by some middleware.
>
>    
not always, basic auth is quite simple, just because it's standart,
It's obviously what's openid/oauth seems to begin to be, the important 
part is not
that you can or not handle it with php or not. I think you'll agree 
about that ;-)

>>>> What I mean when I write "independently from SOAP Api" is that
>>>> security data does not have to be in the SOAP body message part.
>>>>
>>>>          
>>> Uh... well... that may be debated ?
>>>
>>>
>>>        
>> I'm rather in favor of separating auth, like rest does,
>> for the simple reason that you can better choose what you want when it's
>> external.
>>      
> OK, in some kind of middleware, in principle, agreed.
>
> Then anyway, this discussion is a bit vague/void... we might as well try
> and reason on concrete examples ;)
>
>    
the point is here that if auth is embedded, you can't always replace it.
REST don't make any assumption about auth is a concrete exemple, no?
>
>> I don't know much about OAuth but I tend to think you will deal much easier
>> with using it externaly to SOAP than in introducing it in SOAP body
>> message part.
>>
>>      
> I never advocated introducting things into the SOAP payload...
>
> In any case, can we go back discussing the problems (if they be ?) of
> the current approach ?
>
> IIRC, the current SOAP "sessions" go like this :
> 1. call login(login+pass)
> 2. get a cookie
> 3. invoke subsequent methods passing the cookie
>
> Is this really problematic ? And in which concrete ways ?
>
>    
When you don't want SOAP to deal with auth, for exemple you want
- auth with ssl client cert
- auth with kerberos token
- auth with your webapp session cookie (for exemple you have a logged 
session in your prefered EDI, and you'd like to make a SOAP call, you 
would need to reauth or make so the 2 parts use the same cookie)

separate is more flexible, and in most case we live with all these 
multiple auth and poorly
encoded passwd everywhere, I think we'd rather try to go in direction 
that allow to get rid of it.

Cheers

Christian