Log In
Home
06/25/2014
Offline
Part 12 defines:
If a Server supports Push Management it is required to support an information model as part
of its address space. It shall support the ServerConfiguration Object shown in Figure 15. This
Object shall only be visible and accessible to administrators and/or the GDS.
What does “only be visible/accessible” mean in detail?
My assumption:
Accessible – only administrator and/or the GDS can read/write/executable nodes below the ServerConfiguration node.
Visible – only administrator and/or the GDS shall “see” the HasComponent-reference from the ServerObject to the ServerConfiguration object? So the ServerConfiguration node are not shown and a browse on the ServerConfiguration node shall also not possible for non-administrator?
05/30/2017
Offline
From 1.05.2 Draft:
This Object and its immediate children shall be visible (i.e. browse access is available) to users who can access the Server Object. The children of the CertificateGroups Object shall only be visible to Clients with access to the SecurityAdmin Role
06/25/2014
Offline
to users who can access the Server Object
Are there use cases where a client can not use GetMonitoredItems method, ServerCapabilities or e.g. NamespaceArray?
Imho every client shall be able to access the ServerObject.
The children of the CertificateGroups Object shall only be visible to Clients with access to the SecurityAdmin Role
Same question came up.
A Guest client browses ServerConfiguration node and retrieve no reference to the CertificateGroup and the SecAdmin client get this reference by browsing the ServerConfiguration?
05/30/2017
Offline
Imho every client shall be able to access the ServerObject.
Servers don’t have to allow anonymous access. Any Client that can create a Session can access the Server Object.
All of the Nodes of the ServerConfiguration Object have well-known NodeIds so hiding the Nodes does not actually hide anything.
OTOH, the contents of the CertificateGroups folder change from Server to Server so hiding those Nodes does keep sensitive information hidden.
06/25/2014
Offline
the contents of the CertificateGroups folder change from Server to Server so hiding those Nodes does keep sensitive information hidden
Ok, browsing shall return not the references th the Child nodes of object CertificateGroups, this is fine to me.
But, is it enough to set the Variable attribute UserAccessLevel to None? So a read request to NodeId ns=0;i=14161 – CertificateType the attribute value reports BadUserAcessDenied, but the all other NodeAttributes are still readable.
Does this fullfill the requirements?
05/30/2017
Offline
The spec requires that references be suppressed in the Browse response.
Knowledge that a particular CertificateGroup exists could allow a hacker to find an exploit.
06/25/2014
Offline
Knowledge that a particular CertificateGroup exists could allow a hacker to find an exploit.
Ok this means, even a read-request shall not be possible to any node attribute.
May be this should be stated more precisely in the specification.
This Object and its immediate children shall be visible (i.e. browse access or read/write access is available) to users who can access the Server Object. The children of the CertificateGroups Object shall only be visible to Clients with access to the SecurityAdmin Role
05/30/2017
Offline
Ok this means, even a read-request shall not be possible to any node attribute.
Yes that was implied by the language “not visible”. Not browseable, readable, writable or callable.
This “not visible” is the term used in many places in the spec. It is not practical to add the caveat in every location.
Added mantis issue:
1 Guest(s)
Usage Policy