I'm working with a few gateways in a scale-out architecture. I'm trying to introduce security zones that would allow specific front-end clients (identified by either hostname or IP) to be given read/write access via a security zone. The default security zone is set up and has a "read-only" policy for all tag providers.
I've tried setting this security zone up on the back-end initially and tested by placing my own client in that security zone's config (by both hostname and IP). From the client, I'm unable to be placed into that security zone. The only way I could verify this was to momentarily update my Default security zone's policy to read/write for the tags which told me I was being placed in that default zone. I've also tried setting up the same zone on the front end, although I suspect it should reside on the back-end since the tags in that gateway are what the zone is being associated with.
Is there something I'm missing when setting up security zones in the scale-out architecture? Also, is there any way from a front-end client to identify which zones the client is being placed into on any back-ends?
There are lots of contributing factors which might limit one's ability to write to tags.
If Gateway A is hosting tags to a remote provider configured in Gateway B, then Gateway A can be configured to Trust Remote Security Levels as issued to a client at login on Gateway B:
From Service Security:
As of 8.1.2, the Trust Remote Security Levels setting allows users to opt into trusting the Security Levels of remote Gateway users when remote Gateways read, write, and subscribe to local tags.
Despite this very-handy-feature, I'm always nervous using the option for security zones access... Consider the impacts of a client logging in to Gateway B and acquiring an IP-based role there, then being granted write capability on Gateway A, without actually matching the conditions required for the zone on Gateway A. Then again, perhaps that is your goal...
While you're looking at Service Security, check how the remote tag provider is configured for tag writes.
Finally, take advantage of Test a Login from your IdP. While session properties within a client can display the roles that a client is issued, the Test Login feature can offer a little more insight as to 'why'.
From here, a bit more information might be necessary.