Axiom as public facing self-service customer-specific portal
We have a v24 canary historian that collects flow rates from meters. The flow is coming into our pipeline system. The product comes from various customers (approximately 90 different customers). A customer can have 1 or more meters. We'd like to create a public facing portal using Axiom where people can log in and see the flow rates for all of their meters and no other customer meters. Here's my plan, please let me know if you see issues of any kind.
- Create a View where the first level is customer and the 2nd level is meter. The meter asset has the flow rate tag.
- Connect Canary to Entra ID using OpenID
- Create an Entra group for each customer that wants to see their meters
- In Identity, remove default access at the top, and map each Entra group to the appropriate customer asset.
- Create an Axiom application that leverages an Asset Template control to show the flow for all meter assets.
I'm hoping, we can give users access to this one Axiom application and it magically shows them just the meters they have access to.
Questions:
- With the approach above, I think external users would have access to see the Public Folder Axiom displays, even if they couldn't see the data in them. Is it possible to set up a 2nd instance of Axiom on a 2nd server? So that we have an internal facing one and a public facing one?
- There's no way in Canary Identity to say "if a user has an email with domain x, they go to group x" is there? I'm assuming that would have to be done in Entra?
5 replies
-
Hi ,
I think your steps look good. To answer your questions:
- You can set up a 2nd Axiom service, but they would still potentially see other charts/applications in the Public and ReadOnly folder if users start creating their own reports. Are you planning to just provide a url to them and use the ReadOnly mode?
https://helpcenter.canarylabs.com/t/60y8gkg/application-url-parameters-version-24#mode
I will let you know that we do have plans of implementing an Axiom files ACL in the near future. It will be similar to the Tag Security, only it will control which files/folders a user can see in Axiom. - When a user logs in using Axiom (or Excel or the Admin), an internal Canary user is created automatically which is then mapped to the external user coming from the IDP. In your case, that would be Entra. At the same time, all of the external groups that user is a part of are discovered. You can then create an internal Canary group, and map it to one of the external groups that was discovered.
-
Interesting stuff.
- I figured there was no way to stop people from using the Public Folder. And all our displays would be in Read Only, with the assumption that they can be open by anyone, and the data in them would be tailored to their account/company.
- I don't see the value in the ReadOnly Mode, because anyone can just edit the url and get to the full mode, right?
- Ooooh, I like Axiom display ACL. Now, when you say near future.... what are we talking? I see the benefit of that in we could only give our external customers access to a single subfolder in the read only folder. But I'd have to weigh the pros and cons of that vs having a ton of external users and groups and tag ACLs clutter up our internal View service instead of segregating that to a dedicated external View service.
- Let me play this scenario out. I believe you can't manually map an existing Entra Group to Canary Identity. So when we onboard a new customer (which will be in a new Entra Group), we have to have them sign up for Entra, then go to Axiom, try to log, get denied. Then we go into Admin and grant that new group the access we want them to have. Then that user and any future users of that company would be able to get in no problem. Is that an accurate description of the workflow? Or, if they're not in a group that's already mapped to Canary, will Axiom/Identity not even create a user for them when they attempt and fail to log in? Will I need to create a 2nd Entra Group with all customer Entra Groups in it that has no access to any data, but allows them to log in?
- I figured there was no way to stop people from using the Public Folder. And all our displays would be in Read Only, with the assumption that they can be open by anyone, and the data in them would be tailored to their account/company.
-
1.1 - True, but the end-user would have to be aware of that. If a user tries to edit an application from the ReadOnly folder, they cannot overwrite the original. They would have to save it to their own personal folder, or the Public folder.
1.2 - It may be as soon as the next major release which, at this point, will probably be 25.0 next quarter, but I can't say for certain yet.
2 - Your workflow is correct in that the user would initially be denied until their group is discovered, mapped to a Canary group, then given permission within Tag Security. All other subsequent users from that group would then be able to log in without issue. To work around this, you would need to edit the ExternalGroups table in C:\ProgramData\Canary\Identity\identity.sqlite database.
You would probably need to test at least one user to see what the ProviderID, ID, and Name is going to look like in this table. The CanaryGroupID would come from the CanaryGroups table, but you could have all of your Canary Groups created ahead of time and give them permission to the proper branch in Tag Security. All your doing in the ExternalGroups table is creating the entry and mapping it to the existing Canary Group ID.
If a user is not a part of one of these groups, they would still be able to log in and we would create a corresponding Canary user for them. They just wouldn't have access to any data until given permission.
-
Whoa! v25 is coming out that soon?!? Is it a feature breaking as 23 to 24 was?
Interesting option on the SQLite. I'll have to test that out. Thanks!
-
We base our versioning on the year in which it is released. Nothing like 23 to 24 was. That was very atypical of our normal releases. 24 contained a lot of new code that changed how are services run, mainly that we run on .NET core now and migrating from WCF to gRPC.
- You can set up a 2nd Axiom service, but they would still potentially see other charts/applications in the Public and ReadOnly folder if users start creating their own reports. Are you planning to just provide a url to them and use the ReadOnly mode?
Print this page