Another option that just hit me is to have the perl code implement the authentication
interface. This is the target of the <authentication> element in the <handler>
element. See "The Authentication Resource" chapter of the auth dev guide. The format
of the returned information is:
<authentication>
<ID>value</ID>
<role>rolename</role> <!-- optional -->
<data>
... resource specific data for the user
</data>
</authentication>
So as long as your perl can generate this on a socket, just point the handler at it.
This doesn't answer how you would accomplish SSO, but it might be a piece of the
puzzle.
-b
> -----Original Message-----
> From: Brian Topping
> Sent: Sunday, June 09, 2002 7:05 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Cocoon and Integration with Apache
> Authentication/Authorization System
>
>
>
>
> > -----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]>
>
>
---------------------------------------------------------------------
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]>
