You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Vincent Massol <vm...@octo.com> on 2002/01/03 17:33:34 UTC

RE: Adding Authentication To Cactus

Jason,

Sorry for the delay (I have taken the good resolution to try to become
more responsive again for the new year ... as I have noticed a slippage
in my response times ... :-) ).

Thanks for your participation. I'll review your patch now and will give
you my comments later today ...

Peter has also submitted some authentication code so I'll need to merge
both and take the best ;-)

-Vincent

> -----Original Message-----
> From: Robertson, Jason [mailto:Jason.Robertson@acs-inc.com]
> Sent: 28 December 2001 16:34
> To: 'cactus-dev@jakarta.apache.org'
> Subject: Adding Authentication To Cactus
> 
> Howdy all,
> 
> I'm a new Cactus user and I hit a stumbling block right out of the
gate:
> no
> authentication capabilities. So, after a quick check with Vince where
I
> found out there wasn't any active work being done on the topic, I dove
in
> and would like to submit my first-pass solution for review.
> 
> The solution is fairly simple and is designed for expansion, and there
is
> one issue that I will need guidance on what is the proper thing to do
to
> keep with the Cactus "spirit". Also, the solution does revolve around
> basic
> authentication so it may not adapt well to form-based authentication,
but
> I'm hoping it will.
> 
> First, here is the user perspective:
> 
> public void beginSomeTest(WebRequest theRequest)
> {
>     String username = "???";
>     String password = "???";
> 
>     theRequest.setAuthentication(
>         new BasicAuthentication(username, password));
> }
> 
> The WebRequest object was expanded to hold an AbstractAuthentication
> object,
> and currently the only concrete object of this type is
> BasicAuthentication.
> Implementing FormAuthentication will hopefully be straight-forward and
> would
> be used identically by the user.
> 
> The AbstractAuthentication class was designed with the simple
assumption
> that ALL authentication implementations will have a String UserId and
a
> String Password. Two abstract functions validateUserId and
> validatePassword
> provide for concrete implementations to perform character validation.
> 
> All the work is then done in this abstract function:
> 
> void configureAuthentication(HttpURLConnection connection);
> 
> In the BasicAuthentication class, for example, the configuring is done
by
> adding the request property "Authorization" with a value "Basic
> <base64encode of 'userid:password'>".
> 
> In HttpClientHelper, there are now these lines in the connect method:
> 
> AbstractAuthentication authentication =
>     theRequest.getAuthentication();
> 
> if (authentication != null) {
>     authentication.configureAuthentication(connection);
> }
> 
> And it's really as simple as that ... almost.
> 
> In order to make the execution context of my servlet-under-test have
the
> proper authentication, you have to require the same authentication on
> ServletRedirector. So everything is fine with the above code for the
> CALL_TEST service. But then there's the GET_RESULTS service - which
uses
> its
> own WebRequest (and thus doesn't have the authentication information).
The
> call to GET_RESULTS returns with a 401 Unauthorized error.
> 
> To solve this, I hacked it up by passing the original WebRequest into
> callGetResult and pulling the Authentication object from this request
and
> sticking it in the new request. This is where I need some guidance on
what
> would be "proper".
> 
> All the files I modified are attached and should compile with the
12/25/01
> nightly build files.
> 
> One out of one test has passed on my machine so I'm sure my code works
in
> all circumstances everywhere else in the world. :)
> 
> I'm going to look into form authentication this afternoon, but I'm not
> promising anything by the end of the day!
> 
> Small Issues:
> 
> - I didn't use java.security.Principal to hold the userId because it
> didn't
> seem to buy me much. This could easily be changed if necessary.
> - Similarly, commons-httpclient has a UsernamePasswordCredentials
object
> which seems similar to my AbstractAuthentication Object minus the
> configure
> method, but I didn't get the code for it yet and can't verify exactly
what
> is does.
> - Is there a base64Encode method somewhere that I could be using
instead
> of
> pasting my own into the BasicAuthentication class?
> - I put the Abstract & BasicAuthentication objects in the util
package,
> only
> so I wouldn't have to pull any other package into WebReqeust. If they
> belong
> somewhere more appropriate (and I'm betting they do), let me know.
> 
> Jason
> 
> p.s. I'm on vacation all next week, so when I don't reply to anyone
please
> don't think I'm a jerk! :) I'll be back in the office on Jan 7.




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>