Uploaded image for project: 'SAFe Solution'
  1. SAFe Solution
  2. SS-143

Enable a consistent approach to AAA for AA0.5

    XporterXMLWordPrintable

Details

    • Enabler
    • Should have
    • PI23
    • None
    • None
    • Data Processing, Services, Obs Mgt & Controls
    • Hide

      This provides one layer of our security for our production applications. Together, these features will reduce the risk of deliberate or accidental damage to our software systems and data.

      Show
      This provides one layer of our security for our production applications. Together, these features will reduce the risk of deliberate or accidental damage to our software systems and data.
    • Hide
      • For each application we must define and document, to facilitate review by our architect and our security team:
      • a set of user groups, which are mapped on to the application's capabilities, which allow restriction of access based on roles (e.g. restrict roles to read-only access)
      • a set of group managers (must be SKAO staff or associates) - these people will need to manage group membership. We favour smaller groups with well-defined membership. Groups can contain other groups in a hierarchy.
      • timeouts - when do we lock a user's access and force re-authentication (with or without forcing an MFA token refresh)? This can be different for different applications - for applications like Binderhub with the most access, we expect shorter timeouts.
      • activity logs: what user is running what command. Can be more minimal for lower-risk apps, and must be more extensive for higher risk apps.
      • based on activity logs or other indicators, when do we freeze accounts, or raise an alarm/alert?
      • a set of tests to show that you can gain appropriate access if in the correct group, and that access is denied if you are not in the correct group, ideally in an XRAY test plan showing successful test executions. See example mapping on Miro
      • a set of tests to show we are validating tokens appropriately
      • how tokens are acquired and stored and passed around
      Show
      For each application we must define and document, to facilitate review by our architect and our security team: a set of user groups, which are mapped on to the application's capabilities, which allow restriction of access based on roles (e.g. restrict roles to read-only access) a set of group managers (must be SKAO staff or associates) - these people will need to manage group membership. We favour smaller groups with well-defined membership. Groups can contain other groups in a hierarchy. timeouts - when do we lock a user's access and force re-authentication (with or without forcing an MFA token refresh)? This can be different for different applications - for applications like Binderhub with the most access, we expect shorter timeouts. activity logs: what user is running what command. Can be more minimal for lower-risk apps, and must be more extensive for higher risk apps. based on activity logs or other indicators, when do we freeze accounts, or raise an alarm/alert? a set of tests to show that you can gain appropriate access if in the correct group, and that access is denied if you are not in the correct group, ideally in an XRAY test plan showing successful test executions. See example mapping on Miro a set of tests to show we are validating tokens appropriately how tokens are acquired and stored and passed around
    • 12
    • Team_BANG, Team_SKANET, Team_YANDA

    • PI23 - UNCOVERED

    Attachments

      Issue Links

        Parent Of

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4339 ODA: add authorisation to ODA REST API

        • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
        • Analyzing

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4338 ODT: create roles and add authentication to UI and REST API

        • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
        • Analyzing

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4340 OET: access control

        • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
        • Analyzing

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4341 Add authentication to EDA UI and Alarm Handler UI

        • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
        • Analyzing

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4347 Alarm management system: authentication and authorisation

        • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
        • Analyzing

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4348 QA display: authentication and authorisation

        • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
        • Analyzing

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4179 Taranta can authenticate via Microsoft cookie

        • Won't have (this time) - Items labelled as "Won't have", have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, "Won't have" items are not planned into the schedule for the next delivery timebox.
        • Analyzing

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4315 Low Cisco switch hardening inc. AAA implementation - relates to SS-143 (Dependency on IT)

        • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
        • Program Backlog

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4336 BinderHub: Add authorisation (based on role) and accounting; eg events of users logging in

        • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
        • Program Backlog

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4346 EMS: authentication and authorisation in the API gateway

        • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
        • Program Backlog

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4349 Data product dashboard: authentication and authorisation

        • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
        • Program Backlog

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4403 Data lifecycle management: authentication and authorisation

        • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
        • Program Backlog

        Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-4316 Mid Cisco switch hardening inc. AAA implementation - relates to SS-143 (Dependency on IT)

        • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
        • Implementing
        mentioned in

        Page Loading...

        Page Loading...

        Page Loading...

        Page Loading...

        Page Loading...

        Page Loading...

        Page Loading...

        Page Loading...

        Wiki Page

        Wiki Page Loading...

        Features

        Structure

          Activity

            People

              v.allan Allan, Verity
              b.mort Mort, Ben
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Feature Progress

                Story Point Burn-up: (0%)

                Feature Estimate: 12.0

                IssuesStory Points
                To Do00.0
                In Progress   1321.5
                Complete00.0
                Total1321.5

                Capability Progress

                  Feature Point Burn-up: (0%)

                  Capability Estimate: 12

                  CountFeature Points
                  Todo1220
                  In Progress   12
                  Done00
                  Total1321

                  Dates

                    Created:
                    Updated:

                    Structure Helper Panel