nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

making explorer2 more SSO friendly

heymjo

Hi,

I have created a patch that makes the explorer behave nicely when you place it behind an SSO.
Typically when users are authenticated in-container to the web application then request.getUserPrincipal() will give you the current user principal. There is not much to it as you will see from the patch. Since only authentication is affected I'm assuming the UserManager and GroupManager integration for fetching users and groups authorization remains unaffected.

See http://jira.codehaus.org/browse/ACT-833

Thanks
Jorg

Find more posts tagged with

Comments

p4w3l

In my opinion Activiti should externalize identity service more radically. I understand the team wants to deliver complete working out-of-the-box "toy" and must provide own identity service. Unfortunately it is still badly designed: 1. nothing to do with container provided identity ( realms ); and even worse: 2. Pluggability is almost impossible for backends like LDAP. Why not follow something like in Tomcat realms?! Can be implemented also with SQL for having something out-of-the-box but also allow to use existing backends. Who today creates own identity service in every possible system in the company?! I observe and wait patiently for a possibility to connect Acitiviti to external identity backend but still eveluate it as impossible. It is easy to imagine identity backend that doesn't persist passwords today - only a hash. Current Activiti 5.5 version unfortunately needs password in IdentityServiceImpl and CheckPassword so it cannot be used with backends that don't provide passwords.

ronald_van_kuij

1. nothing to do with container provided identity ( realms );

Simply because activity does not need to be be used in a container, so independence of that is needed

2. Pluggability is almost impossible for backends like LDAP.

Might be, feel free to write a decent indepth proposal (preferably in the form of java code) that takes everything into account, so not only solves your issue.

Who today creates own identity service in every possible system in the company?

Maybe you are one of the lucky few where someone else once decided on a one-size-fits-all solution for SSO etc… Many, many companies are not that advanced/progressive etc…

! I observe and wait patiently for a possibility to connect Acitiviti to external identity backend but still eveluate it as impossible

Shame on you… feels like complaying and doing nothing… hmmm gives me not so nice feelings..

p4w3l

You really encouraged me to go Ron! It is my second ( third if I count jBPM ) to make Activiti work with LDAP and please then make following modification in the source code:

replace execute method in org.activiti.engine.impl.cmd.CheckPassword to the following:

&nbsp; public Boolean execute(CommandContext commandContext) {<br>&nbsp;&nbsp; return commandContext.getUserManager().checkPassword(user, password);<br>&nbsp; }<br>

this will delegate user/password check to org.activiti.engine.impl.persistence.entity.UserManager where please add one more method:

&nbsp; public Boolean checkPassword( String user, String password ) {<br>&nbsp;&nbsp; User user = findUserById( user );<br>&nbsp;&nbsp;&nbsp; if ( (user!=null)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; && (password!=null)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; && (password.equals(user.getPassword()))<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return true;<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; return false;&nbsp;&nbsp; <br>&nbsp; }

This will let us override the method in customised UserManager and implement different behaviour like i.e. verification with LDAP bind attempt instead of string compare.

Would you please create the patch for me or I have to learn all that development cycle stuff myself?

ronald_van_kuij

Thanks, greate to called a motivator 🙂 I'll give it a go next week, but creating a real patch is not that hard. Just select both classes in you ide and in the context menu (right click) there must be something about team (eclipse) or something related (netbeans, intellij or whatever)

Oh and make sure all tests run green 😉

Besides that it is also a good idea to create a jira for this (and then attach the patch there) so it won't be forgotten. You may assign that issue to me.

Thanks

ronald_van_kuij

Ouch, stupid me… The original post already contained a jira AND a patch…

p4w3l

I have published my patch in http://jira.codehaus.org/browse/ACT-833

It doesn't change any existing functionality in Activiti only delegates login method from IdentityServiceImpl to UserManager. The second one is pluggable with activiti.cfg.xml and allows to customise login now

It is tested with 5.5 and 5.6 ( all test passed with "ant clean distro" ) and works for me.

Who accepts to incorporate it into next release?

frederikherema1

Last week, I did some refactoring of the Login mechanism of the Explore2 webapp, to allow pluggable authenticating:

- LoggedInUser is now interface
- LoginHandler can be plugged in using spring-contenxt.
- LoginHandler exposes authenticate(user, pwd) and authenticate() (for automatic authentication eg. existing session-data)

So the SSO patch you suggested can be easilly implemented by a LoginHandler. The other patch (moving check to UserManager) makes sense from a plugability perspective and will take this one on trunk this release.

ronald_van_kuij

@frederik: Thanks 🙂

heymjo

Great, thanks !