SSO, users groups, roles, LDAP, etc.

[Migrated From Jforum.net]

Hello!

I like the JForum! Nice job! We would like to use it with SSO but we want to keep our application independent from the JForum as much as it is possible.
Because of these requirements I have a little bit of trouble. Let me describe the situation.

We have users, groups and roles in LDAP and we would like to use the JForum with SSO.
I saw that when a new user logs in via the SSO then the new user is registerd in the JForum.
That is fine but this new guy is registered as a "General" user and we would like to have our users in those groups where they are in our LDAP.
Unfortunatelly it can happen frequently that a user changes groups.
We can create the groups via the admin tool but we do not want to assign our users to their groups manually always when a user wants to join the forum.

In the ControllerUtils.checkSSO(UserSession userSession) method the registration of the new user is implemented after than our customized SSO implementation is called. It looks we cannot solve our user group problem using our SSO implementation because that runs too earlier.

What do you suggest?

Shall I implement a callback in that method? Extending the SSO interface with a new method ... Maybe this solution can be usefull for other people too...

I am an experienced java programmer willing to do the stuff, just need help to direct me to the right direction so that it can be usefull for the whole community.
[originally posted on jforum.net by zet]

[Migrated From Jforum.net]

What approach do you think is good for this situation? Tell me a scenario / way to implement it, so we can discuss about.

As I don't use LDAP, all information you could provide about what do you expect, what does not work, how is a good solution etc etc is very welcome.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Hello Rafael,

Thank you for your quick response!

Our problem is that we have no chance to synchronize our users.
We would like to be called back before the forum saves the userinfo.
We were thinking on a solution and suggesting the following:

The idea is a new interface that is responsible for the interaction of the user data.
For example: "UserInteractionListener". It should work and be configured similarly than
the customization of the SSO.
This interface should provide those call back methods that can keep the user data be synchronized.
Let's see what those can be:

* registerUser(User user);
When a new user object is created it would be nice to be able to set up the object before the DAO saves it.
For example: Setting up the groups of the user.

Method in the SSOUtil class:
public void register(String password, String email) throws Exception
	{
		if (this.exists) {
			return;
		}
		
		// Is a new user for us. Register him
		this.user = new User();
		user.setUsername(this.username);
		user.setPassword(password);
		user.setEmail(email);
		user.setActive(1);
	
		// Get the user interaction listener (NEWINTERFACE_CONCRETECLASS)
		...		
		// Call back the listener if it is available		
		user = NEWINTERFACE_CONCRETECLASS.registerUser(user);
	
		this.dao.addNew(user);
	}

But it is important to modify some methods of GenericDAO because those groups should be saved
that are defined in the User object and the deafult group should be saved only when there is not
any defined group available.

For example the addNew method saves always the default group but the groups can be picked up from the User object:

	public int addNew(User user) throws Exception 
	{
		...
		this.addToGroup(id, new int[] { SystemGlobals.getIntValue(ConfigKeys.DEFAULT_USER_GROUP) });
		...
	}

Same situation ...

	public void addNewWithId(User user) throws Exception 
	{
		...		
		this.addToGroup(user.getId(), new int[] { SystemGlobals.getIntValue(ConfigKeys.DEFAULT_USER_GROUP) });
	}

* syncUserInfo(User user);
Because of having independent systems due to the user data can be changed in one system and the synchronization of
that data becomes neccessary in the other one.
This syncronization can be done when the user session is created/refreshed when the user exists.
For example: user group has changed, user has deleted, etc and it is needed to be synchronized asap.

* changeUserInfo(User user);
When the user profile is going to be modified it would be usefull to be informed before the user data is saved.

* logoutUser(String username);
It would be good to know when a user logs out.

What do u think about it?
[originally posted on jforum.net by zet]

[Migrated From Jforum.net]

Looks interesting and reasonable.

You think you guys are able to help implementing it? Will be a great contribution for the project!

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Hello Raffael,

Thank you for your trust!

Actually I have been working on it already. I am happy to share the implementation of this feature if you agree with it. How should I do it?

In the last few days we have changed the idea and made it a little bit more simple:

The UserInteractionListener should be responsible only for managing the synchronization of user data. This interface should not be responsible for session related operation such as logout or login. If the observation of the logout or the login are needed than the SSO interface should provide these call backs.
Because of a user cannot be deleted in the JForum only two user data operation left to be hooked by the interaction listener: the creation/registration and the modification/update user profile. Therefore the new interface should look like this one:

interface UserInteractionListener {

User createUser(User user);
User changeUser(User user);

}

I am implementing the createUser as I wrote above, in my previous post but for the case of the changeUser method I have no clue yet. Where do you think we shall insert the call(s) for the changeUser method?

Temporarily we do not need to catch the logout so I am not going to implement it now, but later if it becomes necessary I would put it into the SSO interface.

So, this is the status now. I am waiting for your feedback.
[originally posted on jforum.net by zet]

[Migrated From Jforum.net]

Well, the concrete implementation of UserInteractionListener should be defined in the configuration file, among others sso stuff. I guess you're already doing that

changeUser() may be called every time the log in the user in the application, at least. Currently, there are no much data to change, since most stuff used by jforum is forum only - bb code, smilies, signature etc etc... but it could have its applicability.

Also, the "My Profile" page it's an open question. We should completely get rid of it, just remove some options, or keep all and call changeUser()?

I can give you cvs access, if you have an account at java.net

Rafae
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Rafael, Zafe ...

Did anything come of the integration in this thread? I'm working on a similar application using the 2.1.7 codebase, but with a generic custom registry as target for user validation and privilege grants, and a slightly different approach. But of course I'd rather build on existing code, all things equal.

The approach we're taking towards integrating with an enterprise Java app in the same appserver is to entirely replace the jforum database tables as a source of identity information, and while keeping the JForum object model the same, populate the JForum objects with identity information from the enterprise application by means of some custom field mapping at runtime.

So far this involves activating SSO with the usual SSO class (the default is fine!), a replacement of the SSOUtils class that seems to do the heavy lifting for making the user available in the app, a few mods to the ControllerUtilities and maybe some changes to get the groups and roles associated with the User object, hence the overlap with this topic.

Anything current on this or should I forge ahead in a custom way?

The use case is:

1. User logs into master enterprise application
2. Identity is created by the enterprise app
3. User navigates to forum, invoking the ControllerUtilities
4. CU does the usual SSO invocation to establish validity, then invokes the replaced/overridden SSOUtils
5. SSOUtils, now a custom class for a particular integration, constructs a normal JForum User object using custom identity information derived from the enterprise app

To this point I have a working prototype that yields a happy JForum user, but not yet a working JForum app.

Next and maybe last steps are invoking the JForum SecurityRepository to map JForum groups and roles to the JForum user.

I could use some guidance here, in terms of keeping in the spirit of the JForum application. The default permissions model for JForum seems to map multiple roles, each of which controls a permission, to a group, with two groups existing at startup. Is that right?

Are those permissions worked deeply enough into the application that I should leave the roles alone in the database, map groups in the enterprise application to groups in JForum, and use the SecurityRepository to keep doing the group-to-role mapping?

Or does it make more sense to move the roles up to J2EE; that is, define the 5 or 6 JForum roles I see in the database directly in the deployment descriptor and directly map existing Enterprise App J2EE groups to them?

It would be nice if I could do this in a generic enough way that I could kick back to you a configurable SSO that allows for the complete user and group replacement model I'm planning to implement.

I've got some studying to do in how you implement your interfaces for the DAO layer -- I'm used to spring and factories and haven't quite figured out what you're doing to tie the two together. Hints gratefully received.

R.
[originally posted on jforum.net by robinpc]

[Migrated From Jforum.net]

Hi R. ,

I did an implementation nearly a year ago. I sent that to Rafael via e-mail.
I do not know what happened with that implementation but if you need it then I can send it to you. I made it for the 2.1.6 version. It consist of one UserInteractionListener interfaces and some patched Jforum classes where I applied the listener.
We have been using this approach many months ago and works fine.
Regards,
Zet


Hi Rafael,

Congratulation for the new release! Nice job!
Do you remember what happend with those classes that I sent you? I guess the user interaction callback can be usefull for others too.
Regards,
Zet
[originally posted on jforum.net by zet]