[Fusionforge-general] SOAP Api change proposition

[Olivier Berger]

Le jeudi 25 mars 2010 à 11:48 +0100, Laurent HUET a écrit :

> > I'm not sure these can be considered statefull actually...  I think
> > there's a problem of authentication, requiring the passing of a "cookie"
> > with each method invocation, but I doubt the server actually does things
> > in response to a method, by checking prior calls results and/or reusing
> > some stored state in a session saved on server side... but I may be
> > wrong, not having checked in the code.
> 
> Technically, there is a session. I consider that a state is maintained
> at the server side.
> 

OK... well... if you want... but I doubt there is some notion of
"transaction" with a start, actions and a commit with subsequent calls
to SOAP methods, which I would really consider statefull.

> >> - Use only stateless call (security enforced independently from the
> >> SOAP Api)
> >
> > Uh... how's that done in practice ?
> 
> 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).

> SOAP Header (WS-Security) is sometimes used too.

Quick explanation of the principle ?

> 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 ?

> 
> > For REST, we've been investigating the use of OAuth, that seems more
> > interesting than HTTP Basic Auth.
> OAuth is for Authorization and not for Authentification.

Yes, as the final goal is Authorizing invocation of some methods, not
authenticating a user : you want to grant Hudson the right to publish
results of the build, on behalf of a user.

> We can't compare HTTP Basic Auth and OAuth because they are not use
> for the same thing.
> 

Well... with SOAP, we should first mainly care for authorization first :
who's allowed to create a project, a ticket, upload, etc. Then how would
be another thing ;)

> > As for basic auth, I'm not sure all forges can be hosted in contexts
> > where HTTP Basic Auth can be supported, so I might as well see a basic
> > "cookie" used, even though it's just an authentication token, and not
> > really a statefull session token.
> > Are these issues standardized in the SOAP / WS community ?
> 
> The SOAP API have to be designed independently of the security requirements.
> In practice, this meens that the SOAP Body message doen't have to
> carry data for security.
> Each forge can choose the security scheme (WS-Security, SSL
> Certificate, HTTP Basic Auth/Digest, ...)
> 

Right, but privileges on methods that one is allowed to invoke should be
specified somehow, then (authz).

> >> - Use Document/Literal Wrapped for interoperability reason, especially
> >> with .Net and Java world.
> 
> It's difficult to resume Pro/Cons.
> Globally, the main advantage of the Document/Literal Wrapped is that
> your XML request/response can be validated with a Schema and doen't
> carry type encoding infos.
> You'll find more infos here :
> - http://download.microsoft.com/download/6/f/e/6fe941f1-1e8f-43f2-87f7-dd6c4771d045/20070525.PREZ.Interoperabilite_Basique_Services_Web_.NET_et_Java.pptx
> - http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
> 
> > Can frameworks/libs abstract that and the mode be a configuration
> > option / choice on runtime ?
> 
> No, the WSDL contains the configuration mode.
> 

So, that could indeed be detected on runtime, right, then switching teh
way to validate the XML received through HTTP ?

> >> - Use WS-I Basic Profile compliant WSDL
> 
> WS-* specifications are complex and, historically, WS Frameworks
> implementation make different choices (SOAP version, Encoding mode,
> ...).
> The aims of the WS-I profiles is to make these choices.
> When a WS conform to a WS-I Profile, you ensure the interoperability
> with all frameworks that supports this profile.

I fear some overspecifying and losing many of the potential implementors
around here ;)

> 
> > Also, as mentioned by Christian (I think), feature-wise, we might as
> > well use similar APIs on a "semantic" level ("create artifact",
> > "retrieve release") in a "standardized" way, be there implementations in
> > REST, SOAP or whatever (HTML ;). Then maybe some frameworks (Zend ?)
> > might be used to abstract in a powerful enough way, so that the
> > resulting internal API use of the forge's methods is the same
> > (get_artifact() and likes) ?
> 
> These aspects are more internal FF and probably have to be discussed
> in another thread ?
> 

Probably, yes.

Thanks for the interesting discussion.

Best regards,
-- 
Olivier BERGER <olivier.berger at it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)