Access Rights Concept
Key Principles and Terms
Workshop on Access Rights Concept
Frankfurt am Main – 20th of July 2012
1 – Underlying principles
2
Business requirements
on access rights
1.
2.
3.
4.
5.
6.
7.
8.
The party model is based on a hierarchical structure.
Each piece of information belongs to one system entity.
Functions are granted following the hierarchical party model.
Data are granted by the owner system entity.
Access rights are based on a RBAC model.
Access rights management is decentralized.
Access rights granularity is function-based and object-based.
The data scope (in terms of static and transactional data) is
determined by the hierarchical party model.
9. The data scope can be altered (extended and/or reduced) in
some cases.
3
Business requirements
on access rights
1.
The party model is based on a hierarchical structure.
•
•
•
•
Legal relationships between parties in T2S determine a hierarchical party model based
on a three-level structure.
The T2S Operator is the only party on the top level of the hierarchy and it is in a legal
relationship with each party of the second level, i.e. each CSD and each CB in T2S.
Legal relationships also exist between each party belonging to the second level of the
hierarchy (i.e. a CSD or a CB) and all its participants (i.e. CSD participants for the
CSDs and payment banks for the CBs).
Reference: T2S.16.540.
4
Business requirements
on access rights
2. Each piece of information belongs to one system entity.
•
•
•
•
•
System entity management in T2S defines all functionality needed to
support a participating CSD’s or CB’s segregation of processing
capabilities and data across its participants.
A system entity defines the legal entity by which T2S must segregate
the data and access rights of the CSDs and CBs in T2S and the T2S
operator.
The second dimension of system entity management is the
segregation of data across entities.
The configuration of CSDs and CBs as different system entities shall
allow for the partitioning of data on the technical and functional levels
in T2S.
Reference: T2S.11.050.
5
Business requirements
on access rights
3. Functions are granted following the hierarchical party model.
•
•
•
•
This requirement establishes the principle that each parent party is
responsible for assigning the set of T2S services that each of its
participants will be allowed to use.
On this basis, the T2S Operator assigns functions to CSDs and CBs,
each CSD assigns functions to each of its CSD participants, each CB
assigns functions to each of its payment banks.
Different parties within the same system entity may be assigned
different functions on the basis of a specific contractual agreement.
Reference: T2S.04.010, T2S.04.030, T2S.04.060, T2S.04.120.
6
Business requirements
on access rights
4. Data are granted by the owner system entity.
•
•
•
•
Most of the functions apply to data objects.
In this case, an access right refers to the privilege to use a given T2S
functional capability (function scope) on a given object (data scope).
In a typical scenario, one system entity is granting both the function
scope and the data scope, according to the hierarchical party model
(business requirement 9 later on describes exceptions for this typical
scenario).
References: T2S.04.010, T2S.04.030, T2S.04.060, T2S.04.120,
T2S.11.050.
7
Business requirements
on access rights
5. Access rights are based on a RBAC model.
•
•
•
•
•
•
Access rights configuration is based on the following concepts:
privileges, roles, system users, objects and group of objects.
Privileges can be granted as system privileges (i.e. without narrowing
the scope to a single or a homogeneous group of certain static data
objects) or as object privileges (i.e. in relation to a single static data
object or a group of static data objects).
Roles and privileges can be granted as well at object group level
(secured group). Each secured group includes objects of the same
type. The same object may belong to more than one secured group.
Privileges can be grouped into roles.
The access rights profile of a given system user is determined by the
set of roles and privileges granted to it.
Reference: T2S.11.355 to T2S.11.440.
8
Business requirements
on access rights
6.
Access rights management is decentralized.
•
•
•
•
The administrator of the T2S Operator (a) creates roles including the
available privileges, (b) manages users of the T2S Operator, (c) assigns roles
and privileges to these users, (d) creates the administrators of CSDs and
CBs, (e) assigns the relevant roles and privileges to CSDs and CBs.
The administrator of a CSD/CB (a) creates new roles including the available
roles and privileges, (b) manages users of the same CSD/CB, (c) assigns the
available roles and privileges to these users, (d) creates the administrators of
the CSD participants/payment banks of the same CSD/CB, (e) assigns the
available roles and privileges to participants/payment banks of the same
CSD/CB.
The administrator of a CSD participant/payment bank (a) creates new roles
including the available roles and privileges, (b) manages users of the same
CSD participant/payment bank, (c) assigns the available roles and privileges to
these users.
References: T2S.04.030, T2S.04.060, T2S.04.090, T2S.04.120, T2S.04.150.
9
Business requirements
on access rights
7. Access rights granularity is function-based and object-based.
•
•
•
A privilege defines a specific T2S functional capability, e.g. the
settlement of an instruction, a query, a report, a static data update.
Privileges can be granted with specific reference to a given object (e.g.
a securities account) or group of objects (a group of T2S dedicated
cash accounts).
Reference: T2S.11.360, T2S.11.375.
10
Business requirements
on access rights
8. The data scope (in terms of static and transactional data) is
determined by the hierarchical structure.
•
•
•
Each system user is linked to a party.
T2S uses this information to restrict the system user’s access to the
relevant static and transactional data.
Reference: T2S.11.450.
11
Business requirements
on access rights
9.
The data scope can be altered (extended and/or reduced) in some cases.
•
The default data scope of a given system user, determined by its link to the
relevant party is not enough to cover some business scenarios. For example:
•
•
•
•
•
•
CSD participants may need to grant other parties with the privilege to instruct all
their securities accounts or a subset of them (T2S.05.040).
System administrators may need to grant their users with access (display, instruct,
etc.) on a subset of securities accounts or T2S dedicated cash accounts only
(T2S.11.361).
CSDs and CSD participants may grant CBs and payment banks with access
(display) on all their securities accounts or a subset of them (T2S.04.130).
CBs and payment banks may grant CSD participants with access (display) on all
their T2S dedicated cash accounts or a subset of them (T2S.04.040).
The T2S Operator may grant its users with privileges related to business
functions on a subset of CSDs and CBs only (T2S.04.040).
In all these cases, the default data scope of a given system user for a given
function can be extended and/or reduced by means of object privileges.
12
2 – Key terms and their relationships
13
Key terms
1.
T2S user function
•
•
2.
Privilege
•
•
•
•
3.
XML messages and GUI functions are the atomic elements users can trigger in A2A
mode and in U2A mode respectively to interact with T2S.
Based on these set of XML messages and GUI functions, it is possible to define the set
of T2S user functions, i.e. of all the possible actions that a user can trigger in T2S (e.g.
sending a Settlement Instruction, querying the balance of a T2S dedicated cash account,
creating a party, asking for a report, and so forth), either in A2A mode or in U2A
mode.
A privilege identifies the capability of triggering one or several T2S user functions and
it is the basic element to assign access rights to users.
Privileges are classified into system privileges and object privileges.
A system privilege refers to a T2S user function that does not apply to a specific static
or dynamic data object (e.g. a query on the current phase of the settlement day).
An object privilege refers to a T2S user function that applies to a specific static or
dynamic data object (e.g. a T2S user function to display the reference data of a
securities account).
Secured object
•
•
A secured object is a static data object on which a grantee was granted an object
privilege.
The exhaustive list of the possible types of secured objects is as follows: Party;
Security; Securities account; T2S dedicated cash account.
14
Key terms
4.
Secured group
•
5.
Role
•
6.
A secured group is a homogeneous group of secured objects, i.e. a group of secured
objects of the same type (e.g. a group of securities accounts, a group of parties).
A role is a set of privileges. This allows granting and revoking multiple privileges at the
same time.
User
•
•
A user is an individual or application that interact with T2S triggering the available T2S
user functions.
The set of available T2S user functions stems from the set of privileges for which the
user is grantee.
15
Key terms
7.
Data scope
•
•
For each privilege, the hierarchical party model determines the default data scope of
the grantee user, i.e. the set of static or dynamic data objects on which the grantee
user can trigger the relevant T2S user function. More precisely:
• Users of the T2S Operator have visibility on all static and dynamic data objects,
and can act on objects belonging to participants only in exceptional
circumstances, following a specific agreement;
• Users of the CSDs and of the CBs have visibility on all static and dynamic data
objects belonging to the same system entity;
• Users of the CSD participants and of the payment banks have visibility on static
and dynamic data objects that are (directly or indirectly) linked to the same party.
The default data scope of each user can be extended or reduced on the basis of the
actual business needs, by means of object privileges. More precisely:
• Granting a user with a given privilege on a secured object (or on a secured
group) results in extending the data scope of the user by adding the secured
object (or the secured group) to the default data scope of the user.
• Denying a user of a given privilege on a secured object (or on a secured group)
results in reducing the data scope of the user by removing the secured object (or
the secured) from the default data scope of the user.
16
Data scope – Example 1
Default data scope
T2S
Operator
User Z
CSD1
User
Privilege
X
Send settlement instruction
Y
Send settlement instruction
Z
Send settlement instruction
CSD
Part.A
User Y
CSD2
CSD
Part.B
CSD
Part.C
SAC2
SAC3
CSD
Part.D
User X
SAC1
SAC4
SAC5
T2S Operator default data scope
CSD default data scope
CSD participant default data scope
17
Data scope – Example 2
Extended data scope
User
Privilege
User
Privilege
Object
Object Type
X
Send settlement instruction
X
Send settlement instruction
SAC5
Securities Account
T2S
Operator
CSD2
CSD1
CSD
Part.A
CSD
Part.B
CSD
Part.C
SAC2
SAC3
CSD
Part.D
User X
SAC1
SAC4
SAC5
Default data scope
Data scope extension
18
Data scope – Example 3
Extended data scope
User
Privilege
User
Privilege
Object
Object Type
X
Send settlement instruction
X
Send settlement instruction
CDS Part.D
Party
T2S
Operator
CSD1
CSD
Part.A
CSD2
CSD
Part.B
CSD
Part.C
SAC2
SAC3
CSD
Part.D
User X
SAC1
Default data scope
Data scope extension
SAC4
SAC5
19
Data scope – Example 4
Reduced data scope
User
Privilege
Deny
User
Privilege
Object
Object Type
Deny
X
Send settlement instruction
False
X
Send settlement instruction
SAC5
Securities Account
True
T2S
Operator
CSD2
CSD1
CSD
Part.A
CSD
Part.B
CSD
Part.C
SAC1
SAC2
SAC3
CSD
Part.D
SAC5
SAC4
User X
Default data scope
Data scope reduction
20
Key terms
7.
Data scope
•
•
•
The only exception to the data scope principles outlined so far applies for the
securities data objects.
The securities data are created and maintained by one system entity per security, the
so called “Securities Maintaining Entity” (SME), and they can be read by all CSDs
without the configuration of object privileges.
This exception does not apply for market-specific securities attributes and securities
restrictions, as both pieces of information are created, maintained and can be read
only by the owner CSD (i.e. the CSD creating these market-specific securities
attributes or setting these securities restrictions).
21
Relationship between
users and parties
•
Links between users and parties
•
•
•
•
•
Each new user is linked to the same party which the creator user belongs to.
An exception takes place when creating the first user of a party (i.e. when
the T2S Operator, a CSD or a CB create a new system administrator for one
of its participants). In all these cases the created user is linked to the party
this user is going to administer.
Through the link with the relevant party, each user inherits a default data
scope.
The link between a user and a party can not be changed, i.e. a user is always
linked to the same party.
Party administrators
•
Each party must have at least one party administrator, i.e. a user being
granted a specific system privilege that allows its grantee to grant any roles
and privileges previously granted to the grantee’s party.
22
Relationship between
privileges and parties/users
•
•
•
Each privilege, just after its creation, is available to the party administrator(s) of the T2S
Operator only. This means that party administrators of all the other parties can not grant
this privilege to their users.
A privilege becomes available to a party administrator of a party different from the T2S
Operator only after this privilege has been granted to this party. From this moment on, the
party administrator can grant this privilege.
This implies that a two-step process is required in order to grant a specific privilege to a
user belonging to a party different from the T2S Operator. In the first step, the privilege is
granted to the relevant party (so that it becomes available to the party administrator(s) of
this party). With the second step, one of the party administrators grants the privilege to
the relevant user.
Party A
Party B
Grant Privilege P
(step 1)
User X
User Y
Party
Administrator
Party
Administrator
Grant Privilege P
(step 2)
User Z
23
Relationship between
secured objects and secured groups
•
•
•
T2S provides the possibility to create and maintain secured groups, i.e. sets of
secured objects of the same type.
Each newly created secured group is empty, i.e. it does not include any secured
object. After its creation, the secured group can be assigned one or many secured
objects, provided that they are the same type as the secured group. Secured
objects previously assigned to a secured group can also be removed from the same
secured group.
Object privileges can be granted on secured groups to roles, users and parties.
24