[cas-dev] Use of CAS With Basic HTTP Auth?

[Scott Battaglia]

Ed,
While we don't recommend any application obtaining the username/password
besides the CAS application, sometimes its just not possible not too.

If you need a log in token, you have two options:
1. Call GET and parse the login token back and then use it when you POST
2. Reconfigure CAS not to use sessions and thus its always the same lt
(based on the service provided).

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Tue, Jun 10, 2008 at 8:03 PM, Parris, Edward G <edward.g.parris at lmco.com>
wrote:

>  I'm new to CAS and trying it out with a collection of web applications /
> static content spread across several servers/containers (Apache, Tomcat,
> WebLogic). The SSO is working fine for content retrieved by web browsers.
>
>
>
> Now I have some new applications in a J2EE container that need to provide
> content to an application that is only smart enough to support HTTP Basic
> Authentication (GoogleEarth). Even though this application will not gain the
> benefits of SSO I would like to protect the new content using as much of the
> existing CAS infrastructure as possible.
>
>
>
> Although far from an ideal situation (i.e. I've read the discussions
> recommending against this kind of thing) I am playing with an implementation
> of a servlet filter that would do the following:
>
>
>
>    1. Check the input request for a CAS ticket; if one is found do nothing
>    passing the request onto the next filter in the chain.
>    2. If no CAS ticket is found check for the base 64 encoded
>    username/password authorization in the header. If the authorization has not
>    been provided send a 401 back to the client.
>    3. If the username and password are provided open a URL connection to
>    POST to the CAS server login page as a credential acceptor (
>    http://foo.bar.com:9085/cas/login  service=...&username=...&password=...&lt=...). If the response to the POST
>    is a redirect back to the service (i.e. successful login) then the filter
>    would pass the redirect on to the client. If the redirect is back to the
>    login service or some other content then assume the login failed and send
>    another 401 back to the client.
>
>
>
> That's the theory anyway, if I can't get this to work I can fall back on
> the Basic HTTP authentication provided by the container but that would
> require me to configure each of the web containers to access the LDAP
> servers etc. I'd rather not do that if I can avoid it.
>
>
>
> At this point the filter is correctly handling parts 1 and 2 above but I've
> run into problems checking the username and password.
>
>
>
> My first question is if and how a login ticket should be created? Section
> 2.2.2 of the CAS protocol document states that it is required (
> http://www.ja-sig.org/products/cas/overview/protocol/index.html ) but the
> description of the login ticket in section 3.5 seems to be out of date for
> my version of the server (v3.2.1). The server is looking for a login ticket
> with the format of _c<conversationId>_k<continuationId> which seems like
> something the CAS server will need to generate.  Creating my own random IDs
> didn't work and always results in a redirect back to the login page. To get
> this going should I establish a session, post a request to the login page
> without the credentials, then parse the login ticket out of the response and
> finally repost the credentials with the login ticket?
>
>
>
> My second question is if someone else has already solved this problem or
> can recommend a better solution. I can't change the fact that the client
> application only supports HTTP Basic but I'm open to suggestions if you guys
> know a better way of handling this.
>
>
>
> Thanks for your time and consideration,
>
> Ed
>
>
>
>
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080610/91b83254/attachment.html