Dave wrote:
On Wed, May 28, 2008 at 8:03 PM, Allen Gilliland
<[EMAIL PROTECTED]> wrote:
I like Google Docs, but can we get that put into the wiki?
Sure thing. Here it is on the wiki: http://cwiki.apache.org/confluence/x/2lMB
I spent a while learning Acegi stuff so that I could create a custom SSO
integration with our identity system at Sun, so I could add quite a bit more
detail about "Whats going on in security.xml".
Please do, that would be great.
k ... I added a more complete description of how the Acegi filterChain
works along with a description of each of the filters.
I also noted that webservice authentication is completely separate,
which is also an important thing to note for people trying to tie into
other identity systems. Currently we don't do a good job with that :/
There is also no mention of what happens beyond Acegi, which is an important
part of understanding how authentication works in Roller. In particular you
need to know about the RollerSession object and some of the other code in
the ui.core.security package, such as auto provisioning. i.e. how an
authentic user becomes a Roller User object the system can make use of.
I didn't do anything to cover SSO or LDAP integration yet, which is
where auto-provision comes in, no?
Yes and No. Auto provision only makes sense if you are integrating with
a 3rd party identity system, but just because you are using ldap or SSO
doesn't mean you have to do provisioning. This is effectively the heart
of your External User Management proposal right?
What I meant by "beyond Acegi" is that Roller identifies users by using
our User pojo. Acegi doesn't know about our User pojo, it uses it's own
classes and objects. Somewhere in between there is a translation that
happens, which is the RollerSession. We basically take
request.getUserPrincipal() and translate that into a Roller User pojo so
the rest of the Roller code can know about the user.
This is an extremely important part of the authentication process. And
truth be told I think we need to make some improvements here because we
are not entirely consistent in how this works.
I'd also like to add a section that explains how to setup CMA, since
that's what we're using in our Social Software for Glassfish efforts.
As it turns out, we have had a fairly high priority request come in to add
comment authentication to our installation, so I am going to be working on
that very soon. So I should be able to help out with this proposal a bit.
A few quick comments on the proposal ...
* Adding columns to the db for "openid_*" seems a little hokey to me. Is it
not better to find a generic (meaning non-openid specific) way of
accomplishing this? We are bound to run into a situation like this again in
the future and I don't think messing with the schema every time is the best
solution.
* Is it expected that openid users will get a local account provisioned? or
are we planning this such that these users would be managed externally,
similar to an ldap directotry scenario?
* A tricky part that will need more consideration is the comment
authentication part. In particular, Roller currently does not allow a
situation where an authentic user is not also available via lookup in the
UserManager. This will need some revising.
Very interesting. Are you going to do that via OpenID?
No, it's against our custom Sun Identity system. It could work against
OpenID, but that's not specifically what I'm doing.
-- Allen
- Dave
