Feature - Policy Portal using SAML

On e3.20.0 you can not use SAML on the policy portal, this is very inconvenient in particular for those customers on SaaS

  • We need to treat the Policy portal as other portals, where the option is enabled or disabled. If enabled it will inherit the authentication used by eramba.

  • When you create a policy, you have the following options:

  • the “LDAP” authentication required option should be removed. Those that have that option will be migrated to “Private” just in case.

  • In order not to fully loose that functionality, we’ll let people control authorization based on the roles for that document. So there will be a third option called “Only specific groups”, when that option is selected the form will load the custom roles for this module (owner, reviewer and any other created as custom) one below the other with a checkbox or togle. Those custom roles allowed will be able to see these items on the policy.

This will simplify a lot this functionality. Also please move the “Related Policies” item to the “General” tab above the “Published” field.

Github: https://github.com/eramba/eramba/issues/4312

On release 3.23 these changes has been implemented. If you are using the policy portal you will be affected, you need to review three things:

Portal Authentication Settings have been updated and simplified to rely on the main portal authentication system. The screenshots below show the old and the new interface for authentication.

  • If you had the Portal “Disabled”, after the migration this will remain the same (nothing to do)
  • If you had the Portal “Enabled” with some LDAP connector, after the migration this will remain as “Enabled”. Whatever authentication is on the “Main” portal will be used by the policy portal.
  • If you had the Portal “Enabled”, with “Without LDAP”, after the migration this will remain as “Enabled”. Whatever authentication is on the “Main” portal will be used by the policy portal. If have have policies as “Public” they will be accessible by anyone.

Policy Settings (each individual policy) have also been updated to remove the LDAP authentication. The screenshot below shows the old and new options:

  • Policies set as “Public”, after the migration remain the same
  • Policies set as “Private”, after the migration remain the same
  • Policies set as “LDAP”, after the migration will BE MODIFIED TO “Private”. You can change them to Public if you wish.

User Account Settings:

If you want users to be able to authenticate to the “Policy” portal, they will need to be given access on their account to this portal. You will see on release 3.23 an extra option on the Portal setting of accounts that includes “Policy”.

So… I updated to the latest version yesterday (3.23.1) and hit a couple of issues:

1, If you are using Microsoft SAML Authentication then you will need to add the Policy and Awareness Portal URL’s to your Azure SAML Application if you have them enabled or you will get errors.

2, Once I had fixed the SAML issues with the portals I then needed to make the policies visible for users and as they had all been set to Private as per the notice. When I started to edit the policies and set them from Private (Document is not shown on the portal) [fig1] to Only specific groups the Only specific groups option then enables the Custom Roles option and this only shows custom roles that you may have setup through customization for the policies module [fig2]. Surely this should expose Groups and not Custom Roles? To fix this I had to create a new Custom Field (Portal Visibility Group) using the Custom Role option and add the appropriate role to give users access so that it is then selectable from the Custom Roles dropdown [fig3]. Unless I am doing something wrong, this was the only way I could make the Polices visible on the Policy Portal.
Also, it would be great if you could use Bulk Edit for all of the Policies rather than having to manually edit every single document as the option for Only specific groups is not available [fig4].




Hey Kisero,

is my understanding right that, to be able to grant access to policy portal, now every user needs to be added to the eramba user management?

If yes, that would be a blocker for us. Around 1.000 Users have to have access to our policy portal. But I have only about active 40 accounts in the eramba usermanagement. These are the persons which need to have access to the main portal.

At the moment we have 2 AD Groups bound to eramba.
(Users which have an eramba account)
(Users which need access to the policy portal)
At the moment, every policy is linked to the second AD-Group. I don’t need to think about usermanagement here, as this is automatically done by our IT-Team.

Could you please clarify, whether I understood you right, and I have to stop updating eramba, or if I’m wrong.

Thanks a lot


1 Like


Public policies stay public, there is no need to use the account to see them.
When you have policies available only for specific groups, others that are public are available via guest login. You can play with it on our demo instance for better understanding.

Hi Sam, can you share where the demo us? I cant seem to find it.
We have a very similar use case to Wido I guess.

We do not have any public policies at all and scope all policies via LDAP/AD Groups.
For example a client specific document is only available to the specific project team of that client.

So to reiterate Wido’s question, AD Groups are gone and we will need to add users (few hundred in our case) to the eramba user managment, correct?

Thanks, Daniel

Hey Sam,
the policies are not “public” so visible for the whole world. They are bound to an AD-Group, which is managed by our HR and IT departments.

Setting the policies to public is not an options for us as well.



The demo environment is available here: Login Page
I understand, I will test these scenarios and will get back to you.

Adding another voice here. This is a blocker for us since our policy/procedure visibility is tied to AD group membership, which isn’t managed by Security. Like w.franke, we do not have all of our users in eramba, only those who need access to the main portal. Having to manage users and access groups within eramba is a non-starter for us and will mean we need to find a different policy portal solution. What was the rationale for this change?

1 Like

This change has not been good for my company’s implementation.
We host our own Eramba instance behind our own VPN and the Policies Portal was set so that any member of staff just had to click https://eramba.internal.xxxxxx.com/portal/policy/ and the reached the Policy Portal.

Since the upgrade to 3.23,
now everyone arrives at a log in screen

I’ve had about 20 people today asking me ‘how do I log in’.
I tell them ‘just click Login as Guest’ and that works fine, but it’s an annoying extra step and is going to deter staff from accessing company policies.

Is there a way to turn this login prompt off, that the portal doesn’t require authentication?
Like others above have said, we only manage actual Eramba accounts for 20 or 30 staff who are actually involved in compliance and need to use the main portal and modules.

well, no it was not really the intention to let people add groups. You can create a custom role (customisation) on the policy module called “Who can see this policy”, that new role should show up on that setting. Did you try that? I think it should work.

Right, i read this now, so it seems it works.

In your situation I would have done the same.

Agreed, bulk editing policies is not possible because bulk edit controller does not know about the modal javascript logic on the form. This will hopefully be worked out on the new UX/UI.


The same ldap connectors you used to authenticate them, can be used to sync accounts in eramba.

You will assign to all those synched accounts the “Policy Portal” alone and group “no permissions allowed”. The alternative is to make these publics public to all 1000 people, since you do not use authorization to the policies perhaps that is an option.

I think i explained it before, if is not clear contact support Wido.

the same AD you used to authenticate can create accounts using ldap synchronisation, check the feedback we provide Wido above. If you have questions contact support please.

you are syncing users from an AD, if the AD is correct your eramba accounts will be automatically correct. If this is not clear please contact support.