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.
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.
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].
fig1
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.
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?
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?
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.
correct
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.
Sam has confirmed that the change in 3.23.0 is going to make the Policy Portal display a login screen unless every single one of our policies is set to ‘Public’.
This really really does not work well for us, so as advised by Sam, I have posted a feature request to bring the old behaviour back!
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.
@dzl Thanks for sharing, we had to go the same route and use this workaround too.
Unfortunately, we now have all users synced to Eramba, even though they only need to be there to be able to put the Policy Portal behind a login.
Is there any chance functionality to limit access to certain policies to specific AD groups will be returned? This continues to block our ability to upgrade. The workaround above is pretty onerous when dealing with more than a few groups, and I do not need every user in the company to be in eramba.
Sorry to be a smartass, but this issue is irking me to no end.
I just had a new employee which needed to be part of a specific Eramba group but since he was synced I could not edit him. Had to delete his eramba account then manually create it to add him to a different group then the default sync adds him to.
I finally updated, but it seems like I’m going to have to abandon at least the policy portal. There doesn’t seem to be a way to make this manageable when you don’t need your entire user base to have access to every document.
