To solve it properly we could go back to basics and think about how it
"ought to work".
I think the JAAS plugs should not be aware of the MgnlUser at all, and
just focus on the Subject (that's what JAAS do). The functionality the
plugs use to build the Subject is broken out into utility classes so
that it can be reused. The resulting Subject is then used as the basis
for creating the MgnlUser object, which is in turn the object used
internally in Magnolia.
Here's a class diagram showing what it may look like.
http://web.mac.com/algesten/mgnluser.png
I realise this may be idealistic and that there's side-effects and
existing integrations that could cause problems. But I think
establishing a goal would be good before making compromises.
M
On 18 Dec 2008, at 17:10, Grégory Joseph wrote:
Hi Martin,
Thanks for the feedback. This is indeed an area which is hmm.. still
a bit "grey", to stay polite. We've been meaning to clean this up
for a while, but things got in the way.
We might still do something about it for 4.0, but help and patches
would be much appreciated.
See http://jira.magnolia-cms.com/browse/MAGNOLIA-2313 - Fabrizio had
started on this, but we had to revert -- too close to a release, and
potential side-effects on other existing integrations were a concern.
Both your issues are perfectly valid concerns, so we'd really like
to get a good fix on this :)
Cheers,
-g
On Dec 18, 2008, at 4:45 PM, Martin Algesten wrote:
Hey,
I wanted to have a short discussion regarding login. I just managed
to make a single sign-on with our backend system. Users are stored
in magnolia, but the backend system is used for authorization. I
run into two related issues.
1) The intuitive "simple" way of solving single signon doesn't work.
I tried writing my own LoginHandler to be invoked by the LoginFilter.
...
public LoginResult handle(HttpServletRequest request,
HttpServletResponse response) {
if ( isLoggedIntoBackoffice(request) ) {
String username = extractBackofficeUsername(request);
User user =
SecuritySupport
.Factory.getInstance().getUserManager().getUser(username);
MgnlContext.login(user); // doesn't result in a proper login
}
}
...
The user returned by getUser() doesn't have an initialized
User.getSubject() - which means later on
MgnlContext.getAccessManager() doesn't get the right permissions.
It's a little counterintuitive that the user object obtained this
way is not "complete". This leads me on to the second issue.
2) A combination of JCRAuthenticationModule and
JCRAuthorizationModule holds the logic for intializing the
User.getSubject(). It's rather complicated and I'm not sure this is
a good place for it. I especially dislike
JCRAuthorizationModule.setACL() which is private and holds the
logic for grabbing ACLs from the JCR.
If I don't care much for JAAS I'm forced to replicate the subject
intialization which is a) bad to duplicate code and b) rather hard.
Hence I'm pretty much forced down the route of extending one of the
JCRAuXXXModule - which I've done but it's much more complicated
than my "intuitive solution" above - "sledgehammer to crack a nut"
comes to mind.
Currently User.getRoles() and User.getGroups() are populated from
the JCR in MgnlUser, whilst User.getSubject() is populated by the
JAAS plugs. I suggest moving the Subject initialization code to
MgnlUser and as such make UserManager.getUser() return a "complete"
object.
This would "deflate" the complexity of the JAAS plugs - and I would
further suggest refactoring them to inherit a common superclass
rather than one inheriting each other.
I can't see that this would make for much of a change in behaviour
since any 3rd party integration storing groups and/or roles in an
external system is still free to manipulate the User.set/
getSubject() to their heart's content.
Martin
----------------------------------------------------------------
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]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
