> -----Original Message-----
> From: Frank Ridderbusch [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 08, 2002 5:30 PM
> To: cocoon
> Subject: Cocoon and Integration with Apache
> Authentication/Authorization
> System
>
>
> Hi folks,
>
> I'm looking for some ideas/suggestions, how I might integrate
> cocoon better
> with Apache's basic authentication system or the other way around.
>
> I plugged a
> mod_auth_samba module into apache. This allowed me to
> additionally authenticate
> a user against the Windows domain controller (with a little
> local DB file for
> groups/roles).
So if you want to keep SMB as your primary auth, it would make sense to keep it.
Getting a windoze PDC to auth against anything but another PDC is a PITA.
> I'm now looking for an idea, how I can connect apache with
> cocoon in terms
> of authentication and authorization.
>
> - Should cocoon redirect to a apache page, which in turn
> feeds the results
> of the basic authentication back into cocoon? What would I
> need to know
> to do this?
Seems like you could use the RequestGenerator to check the username that the user has
authenticated against in basic auth, redirecting back to the apache pages when there
is no username. You can take that username and build Cocoon credentials from there.
But you can see that this is not secure to someone that can forge HTTP headers, since
they can put a known username in the header with any password, and Cocoon auth has no
way of checking it.
> - Should I use cocoon for authentication and use the
> information in the
> cookie and use the Apache::AuthCookie for the rest of the
> apache/mod_perl
> system. Or the other way around? Start with a basic
> authenticated page,
> stuff the required info into a cookie and use
> Apache::AuthCookie for the
> rest of the apache system and somehow also use the info
> from the cookie
> in the cocoon pipelines.
If a cookie floating across the network gets cracked and it contains a password, an
attacker has a password that they can start logging onto windows shares with. But
it's trivial to decrypt the password that comes with every request of a basic auth
protected site, so I'm guessing crackers aren't a problem on your network. Standard
cookie security uses a session discriminator in the cookie, and the session records
where the connection came from, both address and port. SSL solves the basic auth,
cookie-with-password and man-in-the-middle problems.
So given that you have a session discriminator in a cookie and you are using disparate
modules (mod_jk / tomcat in one and mod_perl in the other), you could solve the dual
login problem with unified session managment. I can't think of a way you are going to
easily get that since sessions are a function of the module and not the apache server.
I could be wrong on that, but the point is, you need to have a session state that is
available to both Tomcat and Perl to have true "single sign on". You could write a
session manager server, but it sounds like a pretty nasty single point of failure.
A very common option is to have the information stored in an LDAP server, since LDAP
is usually the common denominator of fast and secure key-value repositories. If there
was a way to keep an LDAP repository in sync with your PDC, you could have both Perl
and Cocoon auth talk to the LDAP separately, keep separate session contexts, and go
from there. A login to one system could generate a browser redirect to the other
system, the cookie could be read on that system, pushing another login into the second
system. Sounds pretty ugly to me, but it's an option for SSO. And you need to check
availability of LDAP on both platforms. On Cocoon, you would probably use the LDAP
transformer, pipe that into a XSLT Transformer, turn the LDAP transformer output into
something that the authentication action could work with, and you would be golden.
Of course, if you had an LDAP server synchronized to your PDC, you could leave all
your existing perl stuff asis, then just worry about the Cocoon side. I think there
is something like this available for or as an integral part of W2K server.
> I guess, this would mean, I would have to fiddle with JAAS
> to connect
> to the Windows domain controller (I tried to make sense
> from the JAAS
> documentation, but haven't yet really succeded).
JAAS is the future of java authorization and authentication, but it's really
overwhelming to pick up.
Hopefully this doesn't add more questions than answers... there's still a ton of gaps
here, but hopefully a start.
-b
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
