Guide: Entitlement & Eligibility: Difference between revisions

From bwCloud-OS
Jump to navigation Jump to search
← Older edit
VisualWikitext
No edit summary
 
(13 intermediate revisions by 3 users not shown)
Line 5: Line 5:
| style="vertical-align:middle;" | This page is about the entitlements for the bwCloud-OS (Gen3). Please visit [[entitlements for bwCloud-SCOPE|entitlements for bwCloud-OS (Gen2)]] for the legacy information.
| style="vertical-align:middle;" | This page is about the entitlements for the bwCloud-OS (Gen3). Please visit [[entitlements for bwCloud-SCOPE|entitlements for bwCloud-OS (Gen2)]] for the legacy information.
|}
|}
➡️ '''Back to the FAQ for [[Entitlement & Eligibility]].'''
➡️ '''Back to the FAQ for [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''


Entitlements in bwCloud-OS define '''who can access the platform''' ([[Guide: Entitlement & Eligibility#Access Control|Access Control]]), '''how many resources they may use''' ([[Guide: Entitlement & Eligibility#Quota flavors|Quota flavors]]), and '''under what conditions''' ([[Guide: Entitlement & Eligibility#Eligibility|Eligibility]]).
Entitlements in bwCloud-OS define '''who can access the platform''' ([[Guide: Entitlement & Eligibility#Access Control|Access Control]]) and '''how many resources they may use''' '''and under what conditions''' ([[Guide: Entitlement & Eligibility#Eligibility|Eligibility]]).


* Every entitlement contains an eligibility.
* Entitlements are strings assigned to a user carrying information about his/her privileges.
* Every user owns at least the empty entitlement, even if not directly specified.
* Every [[Guide: Entitlement & Eligibility#Quota Entitlements|quota entitlements]] (which can be seen as a "package") contains an eligibility. After "unpacking", the bwCloud-OS works only with the eligibility.
* Every user owns at least the [[Guide: Entitlement & Eligibility#Empty Entitlement|empty eligibility]].
* Every [[Projects and Quota|project]] needs to be linked with an eligibility.
* Every [[Projects and Quota|project]] needs to be linked with an eligibility.


Line 20: Line 21:


== Motivation ==
== Motivation ==
The bwCloud-OS negotiated only contracts with institutions (customers) but not with individual members (users). This is a crucial difference compared to other known cloud providers. Further are severe different types of sponsors (e.g., chairs, research projects) located at the institutes, granting sub-goups of members (users) more resources.
The bwCloud-OS negotiated only contracts with institutions (customers) but not with individual members (users). This is a crucial [[Guide: Charging|difference compared to other known cloud providers]]. Further, there are several different types of sponsors (e.g., faculties, research projects) located at the institutes that need to be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty).


=== Access Control ===
=== Access Control ===
For [[registration]] to the bwCloud-OS several [[Guide: Conditions of use|Guide: Condition of use]] need to be fulfilled. By rolling out the [[Guide: Entitlement & Eligibility#Access Control|access entitlement]] home organization can manage by themselves who is allowed to access the bwCloud-OS.
For [[registration]] to the bwCloud-OS several [[Guide: Conditions of use|Condition of use]] need to be fulfilled. By rolling out the [[Guide: Entitlement & Eligibility#Access Control|access entitlement]] home organizations can manage by themselves who is allowed to access the bwCloud-OS.


=== Automated resource provisioning ===
=== Automated resource provisioning ===
Line 31: Line 32:


=== Charging ===
=== Charging ===
All consumptions within the bwCloud-OS, within projects, are charged. Hence, for each project, a [[Charging|customer]] is required, which differs from the user or owner.
All consumptions within the bwCloud-OS, within projects, are [[Guide: Charging|charged]]. Hence, for each project, a customer is required, which differs from the user or owner.


[[Charging]] will be based on the projects [[Guide: Booking units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|project owner]]'s home organization.  
Charging will be based on the projects [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|project owner]]'s home organization.


=== Delegating resposibility ===
=== Delegating resposibility ===
The user’s home organization can define an internal process, so members can set entitlements in the home IdP.  
The institutes can define an internal process so their members can set entitlements in the home IdP.  


=== Reimbursement ===
=== Reimbursement ===
Entitlements also help define who is financially responsible for producing BEH.
Entitlements also help define who is financially responsible for producing BEH.
* Defining cost centers to separate costs into different cost positions, allowing institutions to reimburse the costs internally.  
* Defining [[Guide: Entitlement & Eligibility#Cost centers|cost centers]] to separate costs into [[Guide: Entitlement & Eligibility#Example eligibility 1|different cost positions]], allowing institutions to reimburse the costs internally.  


* bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing.
* bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing.
Line 47: Line 48:
Sometimes resources should only be consumed up to a certain level or amount of time.
Sometimes resources should only be consumed up to a certain level or amount of time.


* Constraints can be used to manage the valid period for eligibility.
* [[Guide: Entitlement & Eligibility#Constraints|Constraints]] can be used to manage the valid period for eligibility.
* After reaching an eligibility constraint, no more costs can be produced within the associated project.
* After reaching an eligibility constraint, no more costs can be produced within the associated project.
=== Central eligibility platform ===
The gimmic with the eligibility enhances (later) the bwCloud-OS local support to manage quota privileges within the bwCloud-OS environment. Such a [[Guide: REST-API for accounting and resource management#Eligibility rules|central service]] could simplify local processes within the customers.


== Entitlement URN structure ==
== Entitlement URN structure ==
The institutions are sending two types of entitlements to the bwCloud-OS, quota and access entitlements. Often the term 'entitlement' refers only to the quota entitlements.


=== Quota Entitlements ===
=== Quota Entitlements ===
A quota entitlement persists out of two parts, the namespace and the identifier (eligibility):
A quota entitlement consists of two parts, the namespace and the identifier (eligibility):
{| class="mw-message-box mw-message-box-warning"
  <nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
| style="vertical-align:middle;" | '''⚠️ Please Note:''' The namespace is yet not registered and may change.
|}
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group:ELIGIBILITY</nowiki>
bzw.
bzw.
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group</nowiki>:<quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]
  <nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:<quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]
The syntax for valid entitlement identifiers is described in the sections below.
The syntax for valid eligibilitues is described in the sections below.
 
==== Empty Entitlement ====
Each user owns this entitlement implicitly.  This is set for each user within the bwCloud-OS system. This entitlement can also be given explicitly by setting it to a user. Furthermore, this entitlement/ eligibility, and only this, can be used for multiple projects.  


=== Access Entitlement ===
=== Access Entitlement ===
There is also a special entitlement ''access'', which determines whether a user is allowed to access the bwCloud-OS at all. On the level of the bwIDM is this entitlement necessary to [[Registration|register]] for the bwCloud-OS.  
There is also a special entitlement ''access'', which determines whether a user is allowed to access the bwCloud-OS at all. On the level of the bwIDM is this entitlement necessary to [[Registration|register]] for the bwCloud-OS.  
{| class="mw-message-box mw-message-box-warning"
  <nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
| style="vertical-align:middle;" | '''⚠️ Please Note:''' The namespace is yet not registered and may change.
|}
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:access</nowiki>
{| class="wikitable"
{| class="wikitable"
!permition
!permition
Line 92: Line 88:


=== Quota flavors ===
=== Quota flavors ===
A project flavor specifies the maximum resources a project may receive.
The given quota flavor name refers to the quota flavor that specifies the maximum resources a project may receive.


* A user can have several quota flavors.
* A quota flavor can be specified several times by using different cost centers. Each additional eligibility can be used for another project.
* A quota flavor can be specified several times by using different cost centers. Each additional eligibility can be used for another project.
* A user can have several quota flavors.


The supported quota packages are described in the table below.
The given quota flavor name must be within the [[Guide: Project and Quota#List of quota flavors|list of support project quota flavors]].
{| class="wikitable"
 
|+List of supported quota flavors
==== Empty eligibility ====
!quota flavor
Each user owns this eligibility. This is set for each user within the bwCloud-OS environment and can't be removed from a user. An empty quota entitlement can't be given explicitly. Furthermore, this eligibility, and only this, can be used for multiple projects.
!Note
|-
|empty
|Default case. User can’t generate costs.
|-
|tiny_1
|
|-
|xtiny_1
|
|-
|medium_1
|
|-
|xmedium_1
|
|-
|large_1
|
|-
|xlarge_1
|
|-
|custom
|User can choose the quota to be requested.
|}
Each quota flavor is associated with resources granted to [[Projects and Quota|projects]].
{| class="wikitable"
|+Resources associated with each quota flavor
!'''Entitlement'''
!'''instances'''
!'''cores'''
!'''ram_gb'''
!'''volumes'''
!'''volumes_gb'''
!'''backups'''
!'''backups_gb'''
!'''networks'''
!'''subnets'''
!'''routers'''
!'''floating_ips'''
!'''security_groups'''
!'''snapshots'''
|-
|'''empty'''
|0
|0
|0
|0
|0
|0
|0
|0
|0
|0
|0
|20
|0
|-
|'''tiny_1'''
|1
|1
|1
|10
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''xtiny_1'''
|2
|2
|2
|10
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''medium_1'''
|4
|4
|4
|20
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''xmedium_1'''
|8
|8
|8
|20
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''large_1'''
|16
|16
|16
|40
|400
|120
|1200
|20
|20
|2
|2
|20
|40
|-
|'''xlarge_1'''
|32
|32
|32
|40
|400
|120
|1200
|20
|20
|2
| valign="top" |2
|20
|40
|-
|'''custom'''
|*
|*
|*
|*
|*
|*
|*
|*
|*
|*
| valign="top" |*
|*
|
|}


=== Cost centers ===
=== Cost centers ===
Line 277: Line 109:
For a cost center, only the symbols <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.  
For a cost center, only the symbols <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.  


=== First day of validation ===
=== Constraints ===
 
==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' NOT supported yet.
| style="vertical-align:middle;" | '''⚠️ Please Note:''' NOT supported yet.
|}
|}
Specific day in the <code>yyyy-mm-dd</code> format that allows the institute to limit the validation window begin for the eligibility. If the date is not given or <code>null</code>, the following default behavior is: Eligibility is valid from the current day on. '''This feature is currently not supported.'''
Specific day in the <code>yyyy-mm-dd</code> format that allows the institute to limit the validation window to begin for the eligibility. If the date is not given or <code>null</code>, the eligibility is valid from the current day on.


=== Last day of validation ===
==== Last day of validation ====
{| class="mw-message-box mw-message-box-warning"
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' NOT supported yet.
| style="vertical-align:middle;" | '''⚠️ Please Note:''' NOT supported yet.
|}
|}
Specific day in the <code>yyyy-mm-dd</code> format that allows the institute to limit the validation window end for the eligibility. If the date is not given or <code>null</code>, the following default behavior is: Eligibility is forever valid. '''This feature is currently not supported.'''
Specific day in the <code>yyyy-mm-dd</code> format that allows the institute to limit the validation window end for the eligibility. If the date is not given or <code>null</code>, the eligibility is forever valid.


=== Maximal number of booking units ===
==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' NOT supported yet.
| style="vertical-align:middle;" | '''⚠️ Please Note:''' NOT supported yet.
|}
|}
Integer, that defines the maximum number of BEH that can be generated by the associated project. If the number is not given or <code>null</code>, the default behavior is: Eligibility is forever valid. The number of booking units must be at least <code>200</code>. '''This feature is currently not supported.'''
Integer, that defines the maximum number of BEH that can be generated by the associated project. If the number is not given or <code>null</code>, the default behavior is: Eligibility is forever valid. The number of booking units must be at least <code>2000</code>.
 
== Testing ==
We provide a [[Guide: REST-API for accounting and resource management|REST-API]]  that can be used for validating syntax and checking the interpretation of an entitlement and an eligibility.


== Examples ==
== Examples ==


=== Entitlement ===
=== Entitlement examples ===


==== Example entitlement 1 ====
==== Example entitlement 1 ====
{| class="mw-message-box mw-message-box-warning"
Granting a user a request quota for a project up to the medium flavor. All generated booking units will be charged under the bill position ''42.'' Since the constraints section is not defined, the default values are applied.
| style="vertical-align:middle;" | '''⚠️ Please Note:''' The namespace is yet not registered and may change.
  <nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
|}
Granting a user a request quota for a project up to the medium flavor. All generated booking units will be charged under the bill position ''42.''
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
Interpreted as eligibility:
  quota_flavor = medium_1
  quota_flavor = medium_1
Line 316: Line 150:


==== Example entitlement 2 ====
==== Example entitlement 2 ====
Allow a user to request quota for a large project, but this is terminated up to the end of 2026 and can maximally produce <code>5000</code> BEH. The booking units for all projects with the cost center ''student'' will be charged under the same bill position''.''
Allow a user to request a quota for a large project, but this is terminated up to the end of 2026 and can maximally produce <code>5000</code> BEH. The booking units for all projects with the cost center ''student'' will be charged under the same bill position''.''
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
  <nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
Interpreted as eligibility:
  quota_flavor = large_1
  quota_flavor = large_1
Line 330: Line 164:
==== Example entitlement 3 ====
==== Example entitlement 3 ====
A ''xtiny'' project can be requested. The consumed booking units will aggregate under the position for the informatics faculty and can be used from February 2026 on for one year. Costs are allocated to cost center ''hfu_netze2''.
A ''xtiny'' project can be requested. The consumed booking units will aggregate under the position for the informatics faculty and can be used from February 2026 on for one year. Costs are allocated to cost center ''hfu_netze2''.
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group</nowiki>:'''xtiny_1:hfu_netze2:2026-02-01:2027-01-31:null'''
  <nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''xtiny_1:hfu_netze2:2026-02-01:2027-01-31:null'''
Interpreted as eligibility:
Interpreted as eligibility:
  quota_flavor = xtiny_1
  quota_flavor = xtiny_1
Line 343: Line 177:
==== Example entitlement 4 ====
==== Example entitlement 4 ====
A user with this entitlement will book the costs on the cost center ''ufr_technical_faculty'' and must stop when the project consumes <code>1000000</code> BEH.
A user with this entitlement will book the costs on the cost center ''ufr_technical_faculty'' and must stop when the project consumes <code>1000000</code> BEH.
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
  <nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
Interpreted as eligibility:
  quota_flavor = large_1
  quota_flavor = large_1
Line 354: Line 188:
  customer = <nowiki>{{user.home_organization}}</nowiki>
  customer = <nowiki>{{user.home_organization}}</nowiki>


=== Eligibility ===
=== Eligibility examples ===


==== Example eligibility 1 ====
==== Example eligibility 1 ====
The example in the image to the left demonstrates how costs can be accumulated based on cost centers.   
The example in the image to the left demonstrates how costs can be accumulated based on cost centers.   
[[File:Example eligibiliy cost center.drawio.png|thumb|322x322px|Example for eligibility cost centers]]
[[File:Example eligibiliy cost center.drawio.png|thumb|Example for eligibility cost centers|600x600px|left]]

Latest revision as of 11:05, 2 February 2026

⚠️ Please Note: This page is currently under development but kept up to date.
This page is about the entitlements for the bwCloud-OS (Gen3). Please visit entitlements for bwCloud-OS (Gen2) for the legacy information.

➡️ Back to the FAQ for Registration & Entitlements.

Entitlements in bwCloud-OS define who can access the platform (Access Control) and how many resources they may use and under what conditions (Eligibility).

  • Entitlements are strings assigned to a user carrying information about his/her privileges.
  • Every quota entitlements (which can be seen as a "package") contains an eligibility. After "unpacking", the bwCloud-OS works only with the eligibility.
  • Every user owns at least the empty eligibility.
  • Every project needs to be linked with an eligibility.

Every member of a higher education institution in Baden-Württemberg has a personal account. If the institution participates in the federated identity management system (bwIDM), its members can also apply for the external service bwCloud-OS, by providing additional information. This is handled through the assignment of eduPersonEntitlement to the user's account.

All entitlements are issued and managed by the user’s home institution and play a central role in how the platform is used and funded. These decisions are made exclusively by the user's home institution. The bwCloud-OS team has no authority to grant access or resources without an official entitlement.

Motivation

The bwCloud-OS negotiated only contracts with institutions (customers) but not with individual members (users). This is a crucial difference compared to other known cloud providers. Further, there are several different types of sponsors (e.g., faculties, research projects) located at the institutes that need to be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty).

Access Control

For registration to the bwCloud-OS several Condition of use need to be fulfilled. By rolling out the access entitlement home organizations can manage by themselves who is allowed to access the bwCloud-OS.

Automated resource provisioning

Registration is streamlined through entitlements:

  • Entitlements are automatically evaluated during registration.
  • Users receive immediate access and resources (project quota) once their entitlement is confirmed. No manual activation is required.

Charging

All consumptions within the bwCloud-OS, within projects, are charged. Hence, for each project, a customer is required, which differs from the user or owner.

Charging will be based on the projects booking units (BEH) and will be addressed to the project owner's home organization.

Delegating resposibility

The institutes can define an internal process so their members can set entitlements in the home IdP.

Reimbursement

Entitlements also help define who is financially responsible for producing BEH.

  • bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing.

Budget

Sometimes resources should only be consumed up to a certain level or amount of time.

  • Constraints can be used to manage the valid period for eligibility.
  • After reaching an eligibility constraint, no more costs can be produced within the associated project.

Central eligibility platform

The gimmic with the eligibility enhances (later) the bwCloud-OS local support to manage quota privileges within the bwCloud-OS environment. Such a central service could simplify local processes within the customers.

Entitlement URN structure

The institutions are sending two types of entitlements to the bwCloud-OS, quota and access entitlements. Often the term 'entitlement' refers only to the quota entitlements.

Quota Entitlements

A quota entitlement consists of two parts, the namespace and the identifier (eligibility): 

urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY

bzw. 

urn:geant:dfn.de:bwidm:bwcloud-os:group:<quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]

The syntax for valid eligibilitues is described in the sections below.

Access Entitlement

There is also a special entitlement access, which determines whether a user is allowed to access the bwCloud-OS at all. On the level of the bwIDM is this entitlement necessary to register for the bwCloud-OS. 

urn:geant:dfn.de:bwidm:bwcloud-os:access
permition Note
access Allows the registration for the bwCloud-OS via RegApp

Eligibility

Every project is associated with an entitlement, making sure the project is chargeable.

  • An eligibility is a unique combination of owner, quota flavor, and cost center.
  • An eligibility can be assigned to a maximum of one project. The eligibility-project association is therefore unique.
  • A limit value for BEH and validation dates may be set to restrict the duration of an eligibility.

Structure

Optionally, the following structure for Eli may be used to provide further information and define constraints for the quota flavor: 

<quota_flavor>:<cost_center_id>[:CONSTRAINTS]

respectively 

<quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]

Quota flavors

The given quota flavor name refers to the quota flavor that specifies the maximum resources a project may receive.

  • A user can have several quota flavors.
  • A quota flavor can be specified several times by using different cost centers. Each additional eligibility can be used for another project.

The given quota flavor name must be within the list of support project quota flavors.

Empty eligibility

Each user owns this eligibility. This is set for each user within the bwCloud-OS environment and can't be removed from a user. An empty quota entitlement can't be given explicitly. Furthermore, this eligibility, and only this, can be used for multiple projects.

Cost centers

⚠️ Please Note: The cost center can be a random string, making only sense to the home organization.

Cost centers are used to allocate BEH generated within projects. This string does not need to be agreed upon with us and does not need to have any meaning outside the institution.

  • A cost center (id) can be assigned to multiple eligibilities and users.
  • BEH are aggregated per cost center across all projects assigned to the cost center.
  • The assignment of cost centers enables customers to pass on costs (internally).

For a cost center, only the symbols [a-zA-Z0-9-_] and a maximal length of 50 characters are allowed.

Constraints

First day of validation

⚠️ Please Note: NOT supported yet.

Specific day in the yyyy-mm-dd format that allows the institute to limit the validation window to begin for the eligibility. If the date is not given or null, the eligibility is valid from the current day on.

Last day of validation

⚠️ Please Note: NOT supported yet.

Specific day in the yyyy-mm-dd format that allows the institute to limit the validation window end for the eligibility. If the date is not given or null, the eligibility is forever valid.

Maximal number of booking units

⚠️ Please Note: NOT supported yet.

Integer, that defines the maximum number of BEH that can be generated by the associated project. If the number is not given or null, the default behavior is: Eligibility is forever valid. The number of booking units must be at least 2000.

Testing

We provide a REST-API that can be used for validating syntax and checking the interpretation of an entitlement and an eligibility.

Examples

Entitlement examples

Example entitlement 1

Granting a user a request quota for a project up to the medium flavor. All generated booking units will be charged under the bill position 42. Since the constraints section is not defined, the default values are applied. 

urn:geant:dfn.de:bwidm:bwcloud-os:group:medium_1:42

Interpreted as eligibility: 

quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = {{today}}
last_day_of_validation = inf
max_booking_units = inf

owner = {{user.eppn}}
customer = {{user.home_organization}}

Example entitlement 2

Allow a user to request a quota for a large project, but this is terminated up to the end of 2026 and can maximally produce 5000 BEH. The booking units for all projects with the cost center student will be charged under the same bill position. 

urn:geant:dfn.de:bwidm:bwcloud-os:group:large_1:student:null:2026-12-31:5000

Interpreted as eligibility: 

quota_flavor = large_1
cost_center_id = student
first_day_of_validation = {{today}}
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = {{user.eppn}}
customer = {{user.home_organization}}

Example entitlement 3

A xtiny project can be requested. The consumed booking units will aggregate under the position for the informatics faculty and can be used from February 2026 on for one year. Costs are allocated to cost center hfu_netze2. 

urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:2026-02-01:2027-01-31:null

Interpreted as eligibility: 

quota_flavor = xtiny_1
cost_center_id = hfu_netze2
first_day_of_validation = 01.02.2026
last_day_of_validation = 31.01.2027
max_booking_units = inf

owner = {{user.eppn}}
customer = {{user.home_organization}}

Example entitlement 4

A user with this entitlement will book the costs on the cost center ufr_technical_faculty and must stop when the project consumes 1000000 BEH. 

urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1:ufr_technical_faculty:null:null:1000000

Interpreted as eligibility: 

quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = {{today}}
last_day_of_validation = inf
max_booking_units = 1000000

owner = {{user.eppn}}
customer = {{user.home_organization}}

Eligibility examples

Example eligibility 1

The example in the image to the left demonstrates how costs can be accumulated based on cost centers.

Example for eligibility cost centers
Retrieved from "https://wiki.bwcloud-os.de/index.php?title=Guide:_Entitlement_%26_Eligibility&oldid=1807"