Hi Will!

We implemented a "custom login module" for our magnolia installation. Our 
use-case is authentication via the single-sign-on system in use by our 
customer. As such, our solution uses certain attributes of the requests 
(HTTP-Headers) to automatically accept users, without further password entry, 
if they come via the single-sign-on server.

The authentication in Magnolia is divided into 2 parts:

1. The login-handlers
Take a look under config->server->filters->login->loginHandlers ...
The Login Modules are in charge of retrieving authentication tokens (username, 
password), and finally allowing or denying access to the system.

2. The JAAS module
The JAAS module is responsible for authentication against the magnolia 
user-store, and creating the user-"Principal" object.

I needed to put custom logic in both parts - in a custom login-handler to read 
the authentication info from the request-headers, and in the JAAS module in 
order to find the users in magnolia's database using different logic, and 
create missing users on the fly.
In order to pass the authentication information from login-handler to 
JAAS-Module I also needed to write a custom JAAS-Callback-Handler.

Depending on your needs, you may not need to write both parts.
For example, to authenticate users against an external source, it should be 
enough to extend the JAAS-Module with some custom lookup logic.

I made the decision to store (a copy of) each user that logs in, in magnolia's 
users workspace, even though we have those users in the single-sign-on system, 
and in LDAP and AD as well. This is because I wanted to use magnolia's GUI to 
be able to assign ACLs, Roles and Groups to the users, which would otherwise be 
difficult to accomplish.
However, other setups might have fixed authorization strategies (all users from 
a certain domain receive a certain Role, or something like this), in which case 
there is no need to keep a copy of the user-record in magnolia. In this case 
you could create the user-principal on-the-fly, assign required roles, and 
everything should work as expected.

Perhaps someone at Magnolia can confirm whether my take on things is correct, 
as this is a sensitive area to work in (security is important to get right ;-) )

Regards from Vienna,

Richard

-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]] 
Im Auftrag von Will Scheidegger
Gesendet: Mittwoch, 09. Februar 2011 16:54
An: Magnolia User-List
Betreff: [magnolia-user] 2x question concerning external user directory


Dear Magnolians

We're currently working on two projects which will need to authenticate their 
users from an external source. 

One is the "simple" situation: Single logon in a Windows network authenticating 
against an AD. The standard answer would be: Magnolia EE with LDAP and CAS 
module. But in order to convince the customer that this is the way to go I 
wanted to as you about your experience here:
- What do I need to know about the customer's AD setup to be able to tell if 
this works out-of-the-box with Magnolia EE?
- If the setup fits and it works out-of-the-box what kind of 
setup/configuration effort do I need to expect? 
- If EE is not feasible for the customer, has anyone done it with CE? How much 
work was it?

The second scenario is a bit more complicated: A Magnolia CE solution which 
needs to authenticate it's "public" users via WebService against an external 
system. I have not looked into the authentication mechanism to closely yet. We 
talked about it in the Magnolia training though briefly. If someone could give 
me a few pointers where to start (what classes to look at and extend), I'd be 
very grateful. 

Thanks a bunch!

-will


----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------





----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to