Hi Martin,
Sorry for the late reply.
Your ideas sound correct. However, keep in mind that there are several
implementations of User, not just MgnlUser, each using a different
source for their data.
You might want to write this down in the "concepts" page on the wiki -
for instance as a sub page of [1]. If you have patches, feel free to
provide them: small, clear and incremental patches are more likely to
get accepted and applied fast ! :)
Cheers,
-g
[1] http://confluence.magnolia-cms.com/display/DEV/Proposals+-+drafts
On Dec 19, 2008, at 1:35 AM, Martin Algesten wrote:
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]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
