Question

Business Process security for LFDS Users

Workflow Directory Server Version 11 Administration

Updated January 4, 2023

asked on July 21, 2022

Hello, I have moved all my users to Azure AD and that has caused me to use LFDS for authentication which works great. I have set up my users in LFDS as SAML accounts and created groups in LFDS. I then add the groups to the repo in Admin Console. I use these LFDS groups to set access rights and that works just fine too.

I just ran into the next issue. Business processes. I can only select LF groups or Windows groups for the security part of rights on starting BPs. I found someone who said the workaround is to have an LF group in the repo and add the LFDS group to that group, which is totally a workaround that I can do. But when can we expect to see the ability to use LFDS groups in the security tab for BP start rules? Is it on the Road Map at all?

There are going to be more and more folks going to cloud-based authentication so I hope LF is working on getting more compatibility with these SAML accounts.

1 0

Replies

replied on July 22, 2022 • Show version history

Hey Lucas,

We're aware of this. It's more complex to address than it would topically appear. Workflow uses a much older LFS API for Trustee lookups that pre-dates the existence of Directory Server, and thus LFDS groups. That API was never updated to include the ability to reference them. We're likely to deprecate that old outdated API in the intermediate future so it's certainly not getting new features added to it. That means getting direct LFDS group reference support in Workflow requires a big rewrite of all the Workflow Trustee reference/lookup code with newer Directory Server-compatible APIs. Not a trivial undertaking, and there are a lot of high priority items on the Workflow backlog.

Things like this that have inconvenient yet perfectly viable workarounds like nesting LFDS groups in repo groups aren't going to be prioritized as highly over addressing harder blockers and items with only partially functional workarounds. I wish we had infinite resources to take on all the enhancements we want to make, but alas, we do not.

If you know any software engineers on the job market, we're hiring: https://jobs.laserfiche.com/Jobs

1 0

replied on December 28, 2022

It seems that I can find users in the Find User activity if I search on the account name. That will retrieve my users successfully from lfds. BUT......only if those users are NOT in an organization. So only if the users in the ROOT.

Any ideas on how to get users from a specific organization?

0 0

View 3 previous replies

replied on January 3, 2023

Is the LF Server you're connecting to registered in LFDS in the root?

1 0

replied on January 4, 2023 • Show version history

It's a workflow server, so no it isnt registered anywhere. How can I issue a license to a WF server since it does not require one?

What we did, which is not ideal, was to remove all the users from that organization and return them to the root. That allowed everything to work again with some minor tweaks to the WF.

Thanks for the response :)

0 0

replied on January 4, 2023

No, I actually meant to ask about the Laserfiche Server your workflow is connecting to. Because Workflow is not aware of LFDS, it's the Laserfiche Server performing the search when you use a repository trustee provider in Find User.

1 0

replied on January 4, 2023

To finally answer your question: yes the LF Server is in the root. That's why the users are not showing up for the org I am guessing :)

0 0

replied on January 4, 2023 • Show version history

Yes, LFS will "stay in its lane" when searching for users, so it's not going out of its current organization.

Can you walk me through your organizations? Their point was to segregate resources, so I'm not clear on what setup would necessitate a shared LFS with access to ALL organizations.

0 0

replied on January 4, 2023

No we dont need to have a LFS with access to all orgs, just ours. We host 2 customers besides ourselves so they each are an org. We kept all the applications on the root. So segregating resources is exactly what we need. Just trying to do it as smart as possible. Seems like it could go either way of putting the apps in their own org or keep them on the root. The only other factor is that admins such as myself need to be able to access all orgs. We are pretty tight on licenses, strike that, we are excessively and stupidly tight on licenses so the option of an LF admin such as myself having more than one full license is not an option. Help paint the picture a little better? Thanks again!

0 0

You are not allowed to follow up in this post.

Question

Question

Business Process security for LFDS Users

Replies

Sign in to reply to this post.