Roles and Permissions in ODA CA -API & Architecture pattern for ODA Component & Canvas Security

[pecanpete]

This is is linked to E2E-395 Roles and Permissions in ODA CA -API & Architecture pattern for ODA Component & Canvas Security linked. Text form e2eODA e2e-395 attached below

Description Note this will be cross linked with ODA -CA Github ( ref to be added) and may be broken down into sub tasks.

Architecture patterns ODA CA has proposed a Security Identity Management capability documented at: https://tmforum-oda.github.io/oda-ca-docs/caSource/controllers/securityController/README.html

The ODA-CA sequence charts for this implementation - in ODA-CA example Product Catalog -it assumed that Party Roles are hosted within each Component and that changes to Party Roles are notified to the security controller.

Several issues have been identified and need X team Discussion - led by the ODA Security and Privacy Team:

ODA Component team are assuming that all Party Roles are hosted in the Party Management Component ( which uses TMF699 PartyRole. ) ODA CA describes a implementation specific approach which is different from ODA Component. BUT we have yet to approve Stage 2 functional integration pattern - draft is in: https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=221382600 *This is starting to separate stage 2 flow. patterns ( based on Oauth2.0/ Open ID Connect) from possibly multiple implementation approaches and support Parties and devices /applications . Current OAuth 2 pattern used in ODA CA is 'Authorization Code Flow' which is mostly party focussed. For device and systems machine to machine communication i.e. headless ODA components we also need to support OAuth 2.0 Client Credential Flow. Currently it is not clear where the roles should be hosted for parties. Need to define how the OAuth 2.0 Concept of 'Resource Owner' is supported- in ODA which requires a model to be defined and a number of implementation options defined.

API There are several roles based APIs and their use in ODA Security needs to be clarified

TMF672 User Role & Permissions instead of the current ODA-CA implementation based on TMF699 PartyRole. Further complexity is we need to support devices we need also to use TMF720 Digital Identity Management

[LesterThomas]

What has been delivered so far for the Security workstream is just a first step (MVP). We are very open to improvements and our target is a zero-trust model where the Component specification defines all the security requirements using security-as-code approach (extension of infrastructure-as-code). I would be keen to get additional contributors to develop and contribute this if you know of any volunteers!

For the API discussion, our high-level strategy for the relationship between a component and the canvas is as follows:

• The Component developer defines the roles and associated permissions for a component. They also enforce these permissions, as they are the only one's with the data access required for data-based permissions.
• The Canvas includes an Identity Management Service that manages all the system and human identities and their mapping to roles. The same identities will typically be mapped to roles across different components. In order to do this, the Canvas must have information about all the roles defined by each component.
• The Component declares these roles towards the Canvas as part of its component definition. The declaration uses an Open-API so that roles can be added/deleted at run-time for each component. The canvas listens for events using the Open-API event mechanism.

Since our only requirement was for components to communicate roles to the Canvas, we used the TMF699 Party Role API and in the current Level 3 specification, this is a mandatory requirement for all components.

Whilst I understand that there is a TMF672 User Roles & Permissions API and that there may be components that use this as part of their core functionality, we deemed this was not the correct API to use for the Component to Canvas role integration.

[pecanpete]

Lester thanks for the input very helpful and useful is providing some guidance on limiting options . Note that draft https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=221382600 has made similar assumptions and these observations arose out of that study and current work on ODA Components . Look forward to working with ODA CA to address enhancements. including need for Federated identity Management

[brian-burton]

Hi @pecanpete, one thing to clarify here is that the IDM on the ODA CA as it stands is not "in" the canvas, it's "via" the canvas, outside in the wider organisation (although the implementation sits on the same cluster). So the breakdown of responsibilities we've assumed so far takes that into account like this:

• roles and permissions are managed in the component
• identity and access management are out in the wider organisation
• authentication and authorisation are integrated via the front door into the component functional interfaces
• the security controller in the canvas provides abstraction between the component and the organisation's IDM platform so that different organisations can use different IDM platforms and not have to change how roles are advertised.

This leaves me with one significant outstanding question of how/if an actual "user" is provisioned in the component itself or whether the component should trust the authorisation token and create a shadow profile (some kind of skeleton local account) to deal with the settings/logging/state for a correctly authenticate/authorised user. This is important because depending on how we handle it, SCIM is probably preferable to the TM Forum identity APIs.

At the moment, the CA documentation actually only describes the client credentials flow, so that's already in line with what you've said. We can adopt the authorisation code flow as well, and you are right that we should - we simply haven't done it yet because our experience is that sorting out the integration with access management (i.e. dynamically managing roles and attaching component roles to identities) is the harder problem to solve than OAuth 2.0 based authentication and authorisation.

It seems like now is the right time for us to double-check the ODA CA team's assumptions together and then build the authentication and authorisation functionality into the refence as per your team's recommendations so that we can test to make sure that can work and also figure out the answer to my the outstanding account question.

[pecanpete]

Hi Brian - planning to change my Github handle to something more recognisable Agree now is a good time to review where the are across ODA Components and ODA CA For example my reading of the ODACA security documentation had been that this was a Authorization Code flow example but seems you r view is that it is a Client Credential Flow. think this might be be sue of a ODA component assumption about using Party Roles. from my reading some of the models proposed in https://projects.tmforum.org/wiki/display/TAC/TMFC020%3A+Digital+Identity+Management+v1.0.0 and in particular those model in the associated API map in the first comment on this page and the proposed TMF 720 Digital Identity management API( https://github.com/tmforum-apis/TMF720_DigitalIdentity) . Maybe we can plan a X-team meeting on security some time in the New Year?