![Asentria Teleboss 850 Скачать руководство пользователя страница 78](http://html.mh-extra.com/html/asentria/teleboss-850/teleboss-850_user-manual_2981745078.webp)
TeleBoss 850 2.06.280_STD User Manual
Page 72
access when end users configure CPEs, which happens at commissioning time -- presumably the end user does the
commissioning, not a technician from the entity running SitePath. Under restricted trust, end users have master rights
(somebody/something must and in restricted trust mode, it is not SitePath), so they (end users) are the ones that
authorize access.
Fine adjustment
There is also the problem of "how to more finely adjust when a CPE can be accessed", which is where the CPE
authorization feature comes in. CPE authorization means that for each CPE, there is a setting that specifies whether
the CPE is currently authorized for SitePath access (and by extension anyone behind SitePath: its administrator and
its users). In this way, the CPE can be in the SitePath web UI, but not accessible until the end user excplicity
authorizes access, once access is requested by a SitePath user, via the actions configured for the CPE Authrorization
Requested event on the unit (introduced in unit version 2.04.030). This is explained in further detail in the next
paragraph.
When a user clicks the connect button for a CPE, and the CPE is not currently authorized, SitePath causes the unit to
generate an event that means "SitePath wants to access CPE x -- please authorize?". The end user can configure
actions for this event, like emails or traps. So for example the end user could get an email saying "please authorize
CPE x". Once the end user authorizes access, the CPE is accessible from SitePath (and by extension, its
administrator and its users), and the end user can deny access at any time after that. The way that the end user
authorizes and denies access to the unit from SitePath is by browsing to the General->Commission Settings->Network
CPE Devices section of the unit web UI. For each CPE, the end user can choose to
deny
authorize indefinitely
authorize for a set of preset durations (1 hour, 6 hours, 24 hours). When authorizing for these durations, it
means that a timer is set for each CPE for the chosen duration. The unit automatically denies access to that
CPE when that CPE's timer expires, or if the unit is reset.
The ability for SitePath users to route to CPEs depends on both SitePath and the unit. SitePath has its own
permissions architecture for managing who is authorized to access certain CPEs on its end. The unit also has its own
similar permissions architecture for authorizing which CPE is accessible from SitePath, and this is something the end
user has complete and exclusive control over in restricted trust.
In sum, the problem of authorizing CPE access is a legitimate concern for IT administrators. Coarse adjustment of
authorzation happens with the feature of restricted trust. This is a blanket way of saying only certain CPEs are
accessible, and SitePath has limited capability/authority to affect the unit, particularly no authority when it comes to
configuring CPEs. Fine-grain adjustment of authorization happens with the CPE routing authorization feature. So
under restricted trust, the end user blanketly says SitePath:
1. has limited privilege to do certain things,
2. cannot change the CPE configuration, and
3. for the set of configured CPEs, may need additional on-the-fly authorization from the end user. The
authorization and denial of this access all happens through SitePath and the unit. For SitePath users, it
happens through SitePath (in the form of a button labeled "Request Authorization" or Re-request
authorization" in the CPE detail page of the SitePath Web User Interface). For end users, it happens by
browsing to the unit web UI and selecting an authorization option next to a certain CPE.
Also, a single SitePath installation can operate with a mix of units: some commissioned with FULL trust, others
commissioned with RESTRICTED trust.
Содержание Teleboss 850
Страница 6: ......