DSAs

PK Fields

The field that makes a DSA unique in Anjana is:

• name

NOTES:

• The “name” attribute must not contain the character ‘:’ to avoid interfering with the internal logic of the application.

Attributes

When a user accesses the detail of a DSA, the screen displayed is the Attributes screen, where the user can access the different functional, technical, operational, etc. attributes that have been defined in the template, within the corresponding menus and sections, as well as the specific attributes that are not part of the template but have been included in the particular DSA.

The DSA template must contain an attribute to include the terms of the DSA contract. This contract will determine how users subscribed to the DSA will use the dataset data. This attribute can be defined in any menu and section of the DSA template and can be either of type File or of type URL. Internally in Anjana this attribute is ‘termCondFile’.

Another attribute that the DSA must contain is the list of entities that the DSA will encompass. This attribute can be defined in any menu and section of the DSA template and must be of type ENTITY_CONTAINER. The name of this attribute is ‘dsa_content’.

NOTES: 

• Since the DSA corresponds to a group in the identity manager, there are restrictions on their names:

  • GCP IAM does not allow groups whose names contain = < > &

  • Azure does not allow "/ \ [ ] : | < > + = ; ? * , and names must not end in .

  • AWS IAM only allows names made up of letters, numbers and the following characters: + = , . @ _ and -

  • For the LDAP protocol it is recommended that names contain letters, digits and -. It is also advisable to review the protocol implementation used for specific limitations

Relationships

In the relationships screen, the user can view the existing relationships between the DSA and other entities in the Anjana repository.

Relationships can be:

• Direct: Relationships in which the DSA is the source or destination

Relationships can also be filtered by the name and subtype of the related entity, the relationship type (source or destination), and the name and subtype of the relationship.

Lineage

In this screen, the user can view the lineage of the DSA, being able to expand the DSA to see, for example, the organizational unit it belongs to, the users who have access to its data through subscriptions, the data structures it provides access to…

The objects displayed in this graph depend on the lineage layer chosen and their relationship with the DSA (whether it is source, destination and of what type of relationship). It is possible to filter which entity types, relationships and statuses are to be displayed.

More detail about the graph is included in the Lineage section of this Guide.

Stakeholders

Within the Stakeholders screen, the user can view the users who are interested parties of the DSA, including all users subscribed to the DSA.

Users appear typed as:

• Subscribed: user who has a subscription to the DSA 

• Primary: user who created or owns the DSA

• Secondary: user assigned in some attribute of the template (in case the object has some attribute of type Nominal User)

Stakeholders can also be filtered by stakeholder type, role or name.

Audit

Within the Audit screen, the user can view Anjana’s internal audit, where the evolution of the DSA throughout its entire life in the tool can be seen: creation, workflow validations, modifications, subscription requests…

It is possible to filter by whether it is a search action or not, what, who and when an action was performed on that DSA.

The source allows distinguishing among the different sources that generate audit records: “anjana” in the case of internal audit and the system name in the case of external audit.

Versions

List of DSA versions from which the detail of all of them can be accessed.

In this window, the user can:

• Navigate to each of the DSA versions

• Download the snapshot of each DSA version

• In case of having a version pending approval, navigate to its validation workflow