yogsototh/deft
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
deft/notes/xdr_monetization.org
Yann Esposito (Yogsototh) 136c8c4be4
save
2023-08-09 15:00:50 +02:00

8.5 KiB
Raw Blame History

XDR Monetization

Intro

What?

  • Entitlements: What the customer is paying for.
  • Access Rules: What services should allow, restrict.

Example

Entitlements:

  • Tier: Essentials for 1000 users (number of Lees).
  • Extra Data Retention "add-on": 180 days
  • Extra Ingest "add-on": 2 GB

Access Rule example:

  • Total Ingest: 4000GB (1000 user × (2GB + 2GB))
  • Time to Keep Data: 180 days (yes, extra might not mean what we could expect)

ref: https://wwwin-github.cisco.com/cisco-sbgidm/docs/blob/master/provisioning/xdr/xdr-ga.md#entitlements

How?

Entitlement represent what the customer pays for. PIAM creates and updates them.

PIAM -> IROH : enterprise_id,Entitlements
Any -> IROH : /iroh/profile/entitlements
IROH -> Any : Entitlements
PIAM -> IROH : update Entitlements
Any -> IROH : /iroh/profile/entitlements
IROH -> Any : Entitlements

/yogsototh/deft/media/commit/6b27fe6c7103fc493e764ee6f31d6096438b4845/notes/xdr-monetization-piam-entitlements.png

Also Entitlement Summary

IROH exposes an API to retrieve an EntitlementSummary. A data structure easier to consume than the list of entitlements.

PIAM -> IROH : enterprise_id,Entitlements
Any -> IROH : /iroh/profile/whoami
IROH -> Any : enterprise_id,EntitlementSummary
PIAM -> IROH : update Entitlements
Any -> IROH : /iroh/profile/whoami
IROH -> Any : enterprise_id,EntitlementSummary

/yogsototh/deft/media/commit/6b27fe6c7103fc493e764ee6f31d6096438b4845/notes/img/piam-entitlement-summary.png

Entitlements (technically)

Example of a list of Entitlements sent by PIAM to IROH:

Just the Tier, no add-on: 

[{"name" "tier",
  "value" "advantage",
  "quantity" {"value" 1000, "unit" "users"},
  "enforce-quantity" true}]

Tier with add-ons 

[{"name":"tier",
  "value":"essentials",
  "quantity":{"value":1000, "unit":"users"},
  "enforce-quantity":true},
 {"name":"extra_ingest",
  "value":"",
  "quantity":{"value":2, "unit":"GB"},
  "enforce-quantity":true},
 {"name":"extra_data_retention",
  "value":"",
  "quantity":{"value":180, "unit":"days"},
  "enforce-quantity":true}]

PIAM Doc

From Paul Chichonski's doc

https://wwwin-github.cisco.com/cisco-sbgidm/docs/blob/master/provisioning/product-spec.md#multi-valued-attributes

Entitlements

  • entitlements – A list of entitlements the tenant is allowed to use. Each item in the list is an object with the following fields:
[{"name":"tier",
  "value":"essentials",
  "quantity":{"value":1000, "unit":"users"},
  "enforce-quantity":true},
 {"name":"extra_ingest",
  "value":"",
  "quantity":{"value":2, "unit":"GB"},
  "enforce-quantity":true}]

name

  • name – The name of the entitlement (defined as part of the entitlement controlled vocabulary between PIAM and the product)

value

  • value – Some entitlements will have a string value that serves to qualify the entitlement. For example an entitlement with name=tier may have three different manifestations if there are three different tiers (e.g., {"name": "tier", "value": "essentials"}, {"name": "tier", "value": "primary"}, {"name": "tier", "value": "advantage"})

quantity

  • quantity – Some entitlements will have numeric quantity associated with the entitlement, this represents the amount of this entitlement the tenant is permitted to consume. Each quantity field will contain an object with the following values:

    • value - The number holding the actual quantity.
    • unit - A string representing what unit to use when interpreting the quantity.

quantity_enforced

  • quantity_enforced – A boolean field, if true it means that the product should enforce the allocated quantity of the entitlement for this tenant. It is up to the product to determine how to do this. Cases where this will be false are if the customer purchased via a buying program that supports a "pay as you go" pricing model.

Entitlement Summary

The Entitlement Summary provides a data-structure easier to consume than the entitlements list.

  • A JSON Object instead of list.
  • Additional technically useful entries.

Structure

The main structure of the EntitlementSummary is:

{<entitlement-name>: <entitlement-details>}

Where <entitlement-details> looks like:

{"title": "something", // <- optional instead of value:""
 "quantity": Integer,
 "unit": "human-readable-unit",
 "enforce?": Boolean}

Tier-only Entitlement

When PIAM send this list of Entitlements:

[{"name" : "tier",
  "value" : "advantage",
  "quantity" : {"value" : 32000,
                "unit" : "users"},
  "enforce-quantity" : true}]

The EntitlementSummary will look like this: 

{"tier" : {"title" : "advantage",
           "quantity" : 32000,
           "unit" : "users",
           "enforce?" : true}}

With Add-ons

If PIAM send a list of Entitlements with add-ons:

[ {"name" : "tier",
   "value" : "premier",
   "quantity" : {"value" : 1000, "unit" : "users"},
   "enforce-quantity" : true},
  {"name" : "extra_ingest",
   "value" : "",
   "quantity" : {"value" : 2, "unit" : "GB"},
   "enforce-quantity" : true},
  {"name" : "extra_data_retention",
   "value" : "",
   "quantity" : {"value" : 180, "unit" : "days"},
   "enforce-quantity" : true}]

The EntitlementSummary will be: 

{"tier": {"title": "premier",
          "quantity": 1000,
          "unit": "users",
          "enforce?": true},
 "extra_data_retention": {"quantity": 180,
                          "unit": "days",
                          "enforce?": true},
 "extra_ingest": {"quantity": 2,
                  "unit": "GB",
                  "enforce?": true}}

Entitlements consumption in js 

function get_entitlement_tier (entitlements) {
    for (entitlement in org.entitlements) {
        if (entitlement.name == "tier") {
            return entitlement.title;
        }
    }
}
let tier =  get_entitlement_tier (entitlements);

EntitlementSummary consumption in js 

let tier = whoami.org["entitlement-summary"].tier.title;

More to come

IROH Internal

But we plan to add more technical specific values so it helps every Entitlement consumer. That way it would make possible to share between product specific technical values.

For example, we plan to add:

  • a list of allowed modules.
  • an optional list of additional scopes
  • rate limits

XDR global values

If you want us to add some information, so we could centralize some logic related to entitlement into IROH just ask us to add it. Ideally, this should only contain data that could be shared between different modules. For example:

  • allowed workflows, or allowed properties for workflows
  • specific limitations for a specific module (read-only, etc…)

Example 

{"tier": {"title": "premier",
          "quantity": 1000,
          "unit": "users",
          "enforce?": true},
 "extra_data_retention": {"quantity": 180,
                          "unit": "days",
                          "enforce?": true},
 "extra_ingest": {"quantity": 2,
                  "unit": "GB",
                  "enforce?": true},
 // ---- SUMMARY OF TECHNICAL LIMITS
 "summary" {...}}

Summary 

{// ---- SUMMARY OF TECHNICAL LIMITS
 "summary" {
     // PIAM Logic
     "data-retention-in-days": 180, // use extra_data_retention + tier
     "data-maximal-size-in-GB": 4000, // use extra_ingest + tier quantity
     // IROH Internal
     "additional-scopes": [ ... ],  // depends on the tier
     "allowed-modules": [ ... ],    // depends on the tier
     // XDR Shared Global Rules
     "restricted-workflows": [...], // depends on the tier (or something else)
     "rate-limits": // can change depending on the tier
         {"sca": {"queries-per-minutes": "100"},
          "sxo": {"queries-per-minutes": "80"},
          "csc": ...},
     ...
 }
}

Conclusion

  • tier? GET /iroh/profile/whoami then whoami.org["entitlement-summary"].tier.title
  • Summary only: GET /iroh/profile/entitlement-summary
  • raw entitlements: GET /iroh/profile/entitlements