So something I’ve been thinking about a bit is to write a SCIM 2.0 interface to populate the Kinetic Security ID from Azure AD. I would create application roles in Azure AD then push those to Kinetic. Now all my security is centralized and I can do the Separation of Duties work in Azure AD instead of Kinetic. Still early on in the design and not sure what I may find lacking…
1 Like
100% agree. Keeps the admin down to one place for most of the time (i.e. when setting up or changing users role)
2 Likes
For example, will AD only use groups in the /groups push or can I push Application Roles? I would prefer roles since that seems to be the way Microsoft is moving. When checking group membership in web apps, you only get the first 50 or so and have to keep calling the API until you found a match. If you start with the Application, there are many fewer groups to search.
1 Like
I was thinking about the Azure AD side of things in Epicor…
Yes, considering that I made the decision on my security plan largely based on the Epicor University course “Setting Up Interface Security - Classic”, I have to admit I will be unimpressed if the next service pack overwrites the UD Security IDs I have created and assigned to the menus. That said, I have written a BAQ to export the updated menu settings to Excel and intend to use that with DMT to reapply to the Test database when we refresh, so I’m hoping/expecting that I can do the same thing after a service pack if Epicor overwrites their recommended security process.
Of course, I will still have to manually update the 71 Kinetic menus that I can’t seem to get DMT to update, so I will have plenty of time to complain to myself about it.
And I do find the conflicting and/or lack of information worrisome. Considering the intrinsic importance of initial security, I would have expected Epicor to have clearly documented their recommended best practices without documentation that contradicts itself.
No apology necessary!
Any response was appreciated because the Epicor information seems surprisingly limited and I figured this was important enough that I was shocked I could not find a basic beginner’s guide, or even a “hard security lessons I have learned” note. Worst case for me would have been if I had missed something obvious, but at least this thread confirms it wasn’t a dumb question.
Ha, you know, that’s probably a lie. How would I know unless I had done it since the last upgrade? Well I feel stupid.
That is what I originally intended to do until I viewed the “Setting Up Interface Security - Classic” course which pointed me to the UD Security ID method.
That method would be closer in theory to other ERPs I have used, where the Menu ID is linked directly to the Role, but the extra twist in Epicor is that the Security ID is only “almost one-to-one” with the Menu ID. Things like UOM by default have a single Security ID for all 6 occurrences in different parts of the menu tree. If someone can explain to me how that is logical, I’m dying for an explanation. I get why you wouldn’t really need to restrict access to a screen if someone has it in a different area, but why have the default Security ID shared so that you change it in one area, it changes it in all six areas? That kind of makes it hard to set area security without creating a unique Security ID per occurrence, so why not just have 6 IDs by default if you already have 1700+ Security IDs?
It’s worth noting that indeed, this is only User Interface Security. You also can have Field Security, Service Security, API-Keys with Scopes (for Integration workloads), and BAQ security. You can also use Directives for finer security access.
Since one can access Epicor data via REST (or the BLTester for WCF), there is still more work to secure a Kinetic environment.
1 Like
I was trying to restrict the scope to “start small”, but, yes, my reading and experiences so far do make me concerned about possible exposure via REST, so I have to look further into those.
Thanks.
1 Like
Despite the system warning me this is a dead ass conversation, I figured it was important to update just in case any future newbie is searching like I was for what I consider rather important information.
We upgraded to 2022.1.14 and the menus did NOT revert to their original SecurityIDs, so it would appear the SecurityID process did indeed change at version 10.2.
Sorry for waking a dead horse, but thanks again to everyone for your responses!
5 Likes