bwCloud-OS - User contributions [en]

Guide: Enterprise Resource Planning

2026-03-03T15:02:17Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] for overview and management of the [[Guide: Entitlement & Eligibility|entitlements and eligibilities]]. Hence, for managing accounting data and resources of members.

__TOC__

== Motivation ==
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|negotiated only contracts with institutions (customers)]] but not with individual members (users). This is a crucial [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|difference compared to other known cloud providers]].

=== Automated resource provisioning ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Shared resources ===
All resources in the bwCloud-OS are shared between all users. Since everyone should be able to access them, project quota limits are set. However, not every user group (e.g., teacher and student) requires the same [[Guide: Project and Quota#List of quota flavors|quota flavor]].

=== Charging ===
All consumption within the bwCloud-OS, within projects, are [[Guide: Charging|charged]]. 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 ===
The institutes can define an internal process so their members can set entitlements in the home IdP. There are several different types of sponsors (e.g., faculties, research projects) located at the institutes that should be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty). With access to their internal data (e.g., from the local IdP), different eligibilities can be assigned.

=== Reimbursement ===
Entitlements also help define who is financially responsible for producing BEH.
* 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. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned.

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

=== Budget (Not supported yet) ===
Sometimes resources should only be consumed up to a certain level or amount of time.

* [[Guide: Entitlement & Eligibility#Constraints|Constraints]] can be used to manage the valid period for the eligibility.
* After reaching an eligibility constraint, no more costs can be produced within the associated project.

==== Paidafter ====
This may be seen as a 'paidafter' credit (analog to 'prepaid'). Institutes grant their members an amount of BEH to consume. Members can freely choose how to consume those, but not more. After the [[Guide: Charging|payment period]], the institute will only be charged for the consumed BEH.

=== 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.

== Contract relationship bwCloud-OS ==
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers|center]]

Guide: Entitlement & Eligibility

2026-03-03T13:39:58Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

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

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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. This is kind of a "protocol" to communicate with the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning (ERP)]].
* 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.
* Eligibilities are used in the [[Guide: Charging|charging process]].

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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>2000</code>.

== Testing ==
We provide a [[Guide: ERP-API|ERP-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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

Guide: Project and Quota

2026-03-03T13:39:15Z

As1844:

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Fallback. Every user owns this. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty eligibility|empty eligibility.]]
|-
|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
!quota flavor
!'''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" |*
|*
|*
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able to use compute resources. The former assigned eligibility will be free for use again.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Guide: Enterprise Resource Planning

2026-03-02T09:05:53Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] for overview and management of the [[Guide: Entitlement & Eligibility|entitlements and eligibilities]]. Hence, for managing accounting data and resources of members.

__TOC__

== Motivation ==
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|negotiated only contracts with institutions (customers)]] but not with individual members (users). This is a crucial [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|difference compared to other known cloud providers]].

=== Automated resource provisioning ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
All consumption within the bwCloud-OS, within projects, are [[Guide: Charging|charged]]. 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 ===
The institutes can define an internal process so their members can set entitlements in the home IdP. There are several different types of sponsors (e.g., faculties, research projects) located at the institutes that should be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty). With access to their internal data (e.g., from the local IdP), different eligibilities can be assigned.

=== Reimbursement ===
Entitlements also help define who is financially responsible for producing BEH.
* 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. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned.

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

=== Budget (Not supported yet) ===
Sometimes resources should only be consumed up to a certain level or amount of time.

* [[Guide: Entitlement & Eligibility#Constraints|Constraints]] can be used to manage the valid period for the eligibility.
* After reaching an eligibility constraint, no more costs can be produced within the associated project.

==== Paidafter ====
This may be seen as a 'paidafter' credit (analog to 'prepaid'). Institutes grant their members an amount of BEH to consume. Members can freely choose how to consume those, but not more. After the [[Guide: Charging|payment period]], the institute will only be charged for the consumed BEH.

=== 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.

== Contract relationship bwCloud-OS ==
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers|center]]

Guide: Charging

2026-03-02T09:00:59Z

As1844:

{| class="mw-message-box mw-message-box-warning"

| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.

|}

All consumptions within the bwCloud-OS will generate costs the home organizations need to play. The payment period is one year.

== Cost generation ==
A registered user can generate costs like follwing:

# A user brings a [[Guide: Entitlement & Eligibility#Quota Entitlements|quota entitlement]]/ eligibility and requests a [[Projects and Quota|projects with quota]].
# The project will be created, quota set, and members added.
# Every existing VM and volume will produce costs within this project.

=== Cost accumulation examples ===

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

Guide: Enterprise Resource Planning

2026-03-02T08:51:49Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] for overview and management of the [[Guide: Entitlement & Eligibility|entitlements and eligibilities]]. Hence, for managing accounting data and resources of members.

__TOC__

== Motivation ==
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|negotiated only contracts with institutions (customers)]] but not with individual members (users). This is a crucial [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|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).

=== Automated resource provisioning ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
All consumption within the bwCloud-OS, within projects, are [[Guide: Charging|charged]]. 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 ===
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.
* 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. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned.

* 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.

* [[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.

=== 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.

== Contract relationship bwCloud-OS ==
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers|center]]

Guide: Enterprise Resource Planning

2026-02-27T15:56:01Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] for overview and management of the [[Guide: Entitlement & Eligibility|entitlements and eligibilities]]. Hence, for managing accounting data and resources of members.

__TOC__

== Motivation ==
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship 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).

=== Automated resource provisioning ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
All consumption within the bwCloud-OS, within projects, are [[Guide: Charging|charged]]. 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 ===
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.
* 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. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned.

* 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.

* [[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.

=== 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.

== Contract relationship bwCloud-OS ==
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers|center]]

Guide: Entitlement & Eligibility

2026-02-27T15:53:25Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

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

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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. This is kind of a "protocol" to communicate with the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning (ERP)]].
* 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.
* Eligibilities are used in the [[Guide: Charging|charging process]].

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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>2000</code>.

== Testing ==
We provide a [[Guide: ERP-API|ERP-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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

Guide: Enterprise Resource Planning

2026-02-27T15:52:09Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship 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).

=== Automated resource provisioning ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
All consumption within the bwCloud-OS, within projects, are [[Guide: Charging|charged]]. 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 ===
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.
* 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. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned.

* 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.

* [[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.

=== 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.

== Contract relationship bwCloud-OS ==
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers|center]]

Guide: Enterprise Resource Planning

2026-02-27T15:40:25Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship 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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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.

== Contract relationship bwCloud-OS ==
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers|center]]

Guide: Enterprise Resource Planning

2026-02-27T15:39:26Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship 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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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.

== Contract relationship bwCloud-OS ==
[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers]]
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.

Guide: Registration

2026-02-27T15:35:08Z

As1844:

➡️ '''Back to the FAQ for''' '''[[Registration]].'''

__TOC__

== Registration requirements ==
Under [[Guide: Conditions of use|conditions of use]] are the requirements defined that are checked by [https://login.bwidm.de/ bwIDM] before the registration is triggered.
== Automated resource provisioning ==
During the registration on bwIDM for the bwCloud-OS service, the following steps are streamlined:

# A user registers himself*herself.
# bwIDM requests the creation of a user account by the bwCloud-OS and forwards a set of user data.
# The bwCloud-OS parses the user data, including given [[Guide: Entitlement & Eligibility|entitlements]].
# Based on these data, a user account and a start [[Projects and Quota|project]] is created. The [[Guide: Entitlement & Eligibility#Quota flavors|quota flavor]] given in the entitlement defines the project quota. If more than one [[Guide: Entitlement & Eligibility#Quota Entitlements|quota eligibilities]] are given, a random one is chosen. [[Projects and Quota#How can I change the eligibility of a project?|The eligibility can later on be changed.]]

Guide: Entitlement & Eligibility

2026-02-27T15:33:44Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

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

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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.
* Eligibilities are used in the [[Guide: Charging|charging process]].

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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>2000</code>.

== Testing ==
We provide a [[Guide: ERP-API|ERP-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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

Guide: Conditions of use

2026-02-27T15:29:52Z

As1844:

To be able to use ([[Guide: Registration|register]] for) the bwCloud-OS a user needs to fulfill the following conditions:

* Member of a [[Guide: Conditions of use#List of customers|customers]] of bwCloud-OS
* Holding the [[Guide: Entitlement & Eligibility#Access Entitlement|access entitlement]]

__TOC__

== List of customers ==

{| class="mw-message-box mw-message-box-info"
| style="vertical-align:middle;" | This list will be completed soon.
|}

Guide: Entitlement & Eligibility

2026-02-27T15:28:08Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

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

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>2000</code>.

== Testing ==
We provide a [[Guide: ERP-API|ERP-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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

Guide: Entitlement & Eligibility

2026-02-27T15:26:35Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

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

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>2000</code>.

== Testing ==
We provide a [[Guide: ERP-API|ERP-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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

Guide: Entitlement & Eligibility

2026-02-27T15:24:13Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

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]]).

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>2000</code>.

== Testing ==
We provide a [[Guide: ERP-API|ERP-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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

Guide: Charging

2026-02-27T15:24:04Z

As1844:

{| class="mw-message-box mw-message-box-warning"

| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.

|}

All consumptions within the bwCloud-OS will generate costs the home organizations need to play.

== Cost generation ==
A registered user can generate costs like follwing:

# A user brings a [[Guide: Entitlement & Eligibility#Quota Entitlements|quota entitlement]]/ eligibility and requests a [[Projects and Quota|projects with quota]].
# The project will be created, quota set, and members added.
# Every existing VM and volume will produce costs within this project.

=== Cost accumulation examples ===

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

Guide: Charging

2026-02-27T15:23:20Z

As1844:

{| class="mw-message-box mw-message-box-warning"

| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.

|}

All consumptions within the bwCloud-OS will generate costs the home organizations need to play.

== Cost generation ==
A registered user can generate costs like follwing:

# A user brings a [[Guide: Entitlement & Eligibility#Quota Entitlements|quota entitlement]]/ eligibility and requests a [[Projects and Quota|projects with quota]].
# The project will be created, quota set, and members added.
# Every existing VM and volume will produce costs within this project.

=== Eligibility examples ===

==== Example eligibility 1 ====
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|Example for eligibility cost centers|600x600px|left]]

Guide: Charging

2026-02-27T15:22:29Z

As1844:

{| class="mw-message-box mw-message-box-warning"

| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.

|}

All consumptions within the bwCloud-OS will generate costs the home organizations need to play.

== Cost generation ==
A registered user can generate costs like follwing:

# A user brings a [[Guide: Entitlement & Eligibility#Quota Entitlements|quota entitlement]]/ eligibility and requests a [[Projects and Quota|projects with quota]].
# The project will be created, quota set, and members added.
# Every existing VM and volume will produce costs within this project.

Guide: Enterprise Resource Planning

2026-02-27T15:22:22Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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.

== Contract relationship bwCloud-OS ==
[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers]]
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.

Guide: ERP-API

2026-02-27T15:21:30Z

As1844:

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

The bwCloud-OS provides an ERP with a RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage entitlements and eligibilities.

__TOC__

== Entitlement ==

=== Entitlement validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of an entitlement string.

==== Entitlement validation example 2 ====
JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2025-12-19', 'last_day_of_validation': 'inf', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 2'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2026-02-01', 'last_day_of_validation': '2027-01-31', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 3'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null</nowiki>"}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

== Eligibility ==

=== Eligibility rules ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' Providing this functionalities is optional and still to plan.
|}
This endpoint may be extended to allow customers to manage eligibility. By defining rules that can be applied to bwCloud-OS users when matching certain criteria. ''E.g. If the user is a member of the medicine faculty, grant the small quota flavor.'' However, the use cases and requirements for this are yet not cleare.

* As a customer, I want a service where my local support can define rules for rolling out eligibility, such that new users from my organization gain automatic quotas.
* As a customer, I want to control who is allowed to manage and see cost centers, user groups, and personal information, such that only privileged people can grant quotas.
* As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)
* As a user, I want to see the eligibilities I am owning, such that I can plan how to debit these.

There are plenty of questions the bwCloud-OS needs to address to their customers before it gets clear what kind of centralized service actually is needed and weather it will be accepted.

=== Eligibility validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of eligibility data.

'''Eligibility validation example 1'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}</code>

Return: <code>{'quota_flavor': 'large_1', 'cost_center_id': 'student', 'first_day_of_validation': '2026-01-01', 'last_day_of_validation': '2026-12-31', 'max_number_of_booking_units': 5000}</code>

'''Eligibility validation example 2'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

Guide: ERP-API

2026-02-27T15:21:21Z

As1844:

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''
The bwCloud-OS provides an ERP with a RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage entitlements and eligibilities.

__TOC__

== Entitlement ==

=== Entitlement validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of an entitlement string.

==== Entitlement validation example 2 ====
JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2025-12-19', 'last_day_of_validation': 'inf', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 2'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2026-02-01', 'last_day_of_validation': '2027-01-31', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 3'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null</nowiki>"}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

== Eligibility ==

=== Eligibility rules ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' Providing this functionalities is optional and still to plan.
|}
This endpoint may be extended to allow customers to manage eligibility. By defining rules that can be applied to bwCloud-OS users when matching certain criteria. ''E.g. If the user is a member of the medicine faculty, grant the small quota flavor.'' However, the use cases and requirements for this are yet not cleare.

* As a customer, I want a service where my local support can define rules for rolling out eligibility, such that new users from my organization gain automatic quotas.
* As a customer, I want to control who is allowed to manage and see cost centers, user groups, and personal information, such that only privileged people can grant quotas.
* As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)
* As a user, I want to see the eligibilities I am owning, such that I can plan how to debit these.

There are plenty of questions the bwCloud-OS needs to address to their customers before it gets clear what kind of centralized service actually is needed and weather it will be accepted.

=== Eligibility validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of eligibility data.

'''Eligibility validation example 1'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}</code>

Return: <code>{'quota_flavor': 'large_1', 'cost_center_id': 'student', 'first_day_of_validation': '2026-01-01', 'last_day_of_validation': '2026-12-31', 'max_number_of_booking_units': 5000}</code>

'''Eligibility validation example 2'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

Guide: Enterprise Resource Planning

2026-02-27T15:21:04Z

As1844:

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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.

Guide: Enterprise Resource Planning

2026-02-27T15:20:49Z

As1844:

__TOC__

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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.

Guide: Enterprise Resource Planning

2026-02-27T15:20:15Z

As1844:

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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.

Guide: ERP-API

2026-02-27T15:19:33Z

As1844:

The bwCloud-OS provides an ERP with a RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage entitlements and eligibilities.

__TOC__

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

== Entitlement ==

=== Entitlement validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of an entitlement string.

==== Entitlement validation example 2 ====
JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2025-12-19', 'last_day_of_validation': 'inf', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 2'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2026-02-01', 'last_day_of_validation': '2027-01-31', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 3'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null</nowiki>"}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

== Eligibility ==

=== Eligibility rules ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' Providing this functionalities is optional and still to plan.
|}
This endpoint may be extended to allow customers to manage eligibility. By defining rules that can be applied to bwCloud-OS users when matching certain criteria. ''E.g. If the user is a member of the medicine faculty, grant the small quota flavor.'' However, the use cases and requirements for this are yet not cleare.

* As a customer, I want a service where my local support can define rules for rolling out eligibility, such that new users from my organization gain automatic quotas.
* As a customer, I want to control who is allowed to manage and see cost centers, user groups, and personal information, such that only privileged people can grant quotas.
* As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)
* As a user, I want to see the eligibilities I am owning, such that I can plan how to debit these.

There are plenty of questions the bwCloud-OS needs to address to their customers before it gets clear what kind of centralized service actually is needed and weather it will be accepted.

=== Eligibility validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of eligibility data.

'''Eligibility validation example 1'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}</code>

Return: <code>{'quota_flavor': 'large_1', 'cost_center_id': 'student', 'first_day_of_validation': '2026-01-01', 'last_day_of_validation': '2026-12-31', 'max_number_of_booking_units': 5000}</code>

'''Eligibility validation example 2'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

Guide: Entitlement & Eligibility

2026-02-27T15:17:56Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise Resource Planning]].'''

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]]).

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>2000</code>.

== Testing ==
We provide a [[Guide: ERP-API|ERP-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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

=== Eligibility examples ===

==== Example eligibility 1 ====
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|Example for eligibility cost centers|600x600px|left]]

Guide: Enterprise Resource Planning

2026-02-27T15:16:37Z

As1844:

The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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.

Guide: ERP-API

2026-02-27T15:15:02Z

As1844: Created page with "The bwCloud-OS provides an ERP with a RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage entitlements and eligibilities. __TOC__ == Entitlement == === Entitlement validation === {| class="mw-message-box mw-message-box-warning" | style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon. |}This endpoint can be us..."

The bwCloud-OS provides an ERP with a RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage entitlements and eligibilities.

__TOC__

== Entitlement ==

=== Entitlement validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of an entitlement string.

==== Entitlement validation example 2 ====
JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2025-12-19', 'last_day_of_validation': 'inf', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 2'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2026-02-01', 'last_day_of_validation': '2027-01-31', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 3'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null</nowiki>"}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

== Eligibility ==

=== Eligibility rules ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' Providing this functionalities is optional and still to plan.
|}
This endpoint may be extended to allow customers to manage eligibility. By defining rules that can be applied to bwCloud-OS users when matching certain criteria. ''E.g. If the user is a member of the medicine faculty, grant the small quota flavor.'' However, the use cases and requirements for this are yet not cleare.

* As a customer, I want a service where my local support can define rules for rolling out eligibility, such that new users from my organization gain automatic quotas.
* As a customer, I want to control who is allowed to manage and see cost centers, user groups, and personal information, such that only privileged people can grant quotas.
* As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)
* As a user, I want to see the eligibilities I am owning, such that I can plan how to debit these.

There are plenty of questions the bwCloud-OS needs to address to their customers before it gets clear what kind of centralized service actually is needed and weather it will be accepted.

=== Eligibility validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of eligibility data.

'''Eligibility validation example 1'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}</code>

Return: <code>{'quota_flavor': 'large_1', 'cost_center_id': 'student', 'first_day_of_validation': '2026-01-01', 'last_day_of_validation': '2026-12-31', 'max_number_of_booking_units': 5000}</code>

'''Eligibility validation example 2'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

Guide: Entitlement & Eligibility

2026-02-27T15:12:45Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise_Resource_Planning]] .'''

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]]).

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>2000</code>.

== Testing ==
We provide a [[Guide: ERP-API|ERP-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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

=== Eligibility examples ===

==== Example eligibility 1 ====
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|Example for eligibility cost centers|600x600px|left]]

Guide: Enterprise Resource Planning

2026-02-27T14:53:21Z

As1844:

The bwCloud-OS provides an ERP with a RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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 ==

=== Entitlement validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of an entitlement string.

==== Entitlement validation example 2 ====
JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2025-12-19', 'last_day_of_validation': 'inf', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 2'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2026-02-01', 'last_day_of_validation': '2027-01-31', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 3'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null</nowiki>"}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

== Eligibility ==

=== Eligibility rules ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' Providing this functionalities is optional and still to plan.
|}
This endpoint may be extended to allow customers to manage eligibility. By defining rules that can be applied to bwCloud-OS users when matching certain criteria. ''E.g. If the user is a member of the medicine faculty, grant the small quota flavor.'' However, the use cases and requirements for this are yet not cleare.

* As a customer, I want a service where my local support can define rules for rolling out eligibility, such that new users from my organization gain automatic quotas.
* As a customer, I want to control who is allowed to manage and see cost centers, user groups, and personal information, such that only privileged people can grant quotas.
* As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)
* As a user, I want to see the eligibilities I am owning, such that I can plan how to debit these.

There are plenty of questions the bwCloud-OS needs to address to their customers before it gets clear what kind of centralized service actually is needed and weather it will be accepted.

=== Eligibility validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of eligibility data.

'''Eligibility validation example 1'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}</code>

Return: <code>{'quota_flavor': 'large_1', 'cost_center_id': 'student', 'first_day_of_validation': '2026-01-01', 'last_day_of_validation': '2026-12-31', 'max_number_of_booking_units': 5000}</code>

'''Eligibility validation example 2'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

Guide: Entitlement & Eligibility

2026-02-27T14:52:33Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

➡️ '''To the [[Guide: Enterprise Resource Planning|Enterprise_Resource_Planning]] .'''

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]]).

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__
== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>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 ==

=== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

=== Eligibility examples ===

==== Example eligibility 1 ====
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|Example for eligibility cost centers|600x600px|left]]

Guide: Enterprise Resource Planning

2026-02-27T14:50:08Z

As1844:

The bwCloud-OS provides an RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

__TOC__

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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 ==

=== Entitlement validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of an entitlement string.

==== Entitlement validation example 2 ====
JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2025-12-19', 'last_day_of_validation': 'inf', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 2'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2026-02-01', 'last_day_of_validation': '2027-01-31', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 3'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null</nowiki>"}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

== Eligibility ==

=== Eligibility rules ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' Providing this functionalities is optional and still to plan.
|}
This endpoint may be extended to allow customers to manage eligibility. By defining rules that can be applied to bwCloud-OS users when matching certain criteria. ''E.g. If the user is a member of the medicine faculty, grant the small quota flavor.'' However, the use cases and requirements for this are yet not cleare.

* As a customer, I want a service where my local support can define rules for rolling out eligibility, such that new users from my organization gain automatic quotas.
* As a customer, I want to control who is allowed to manage and see cost centers, user groups, and personal information, such that only privileged people can grant quotas.
* As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)
* As a user, I want to see the eligibilities I am owning, such that I can plan how to debit these.

There are plenty of questions the bwCloud-OS needs to address to their customers before it gets clear what kind of centralized service actually is needed and weather it will be accepted.

=== Eligibility validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of eligibility data.

'''Eligibility validation example 1'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}</code>

Return: <code>{'quota_flavor': 'large_1', 'cost_center_id': 'student', 'first_day_of_validation': '2026-01-01', 'last_day_of_validation': '2026-12-31', 'max_number_of_booking_units': 5000}</code>

'''Eligibility validation example 2'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

Guide: Entitlement & Eligibility

2026-02-27T14:49:49Z

As1844:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

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]]).

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__

== 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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>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 ==

=== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

=== Eligibility examples ===

==== Example eligibility 1 ====
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|Example for eligibility cost centers|600x600px|left]]

Guide: REST-API for accounting and resource management

2026-02-27T14:46:14Z

As1844: As1844 moved page Guide: REST-API for accounting and resource management to Guide: Enterprise Resource Planning

#REDIRECT [[Guide: Enterprise Resource Planning]]

Guide: Enterprise Resource Planning

2026-02-27T14:46:14Z

As1844: As1844 moved page Guide: REST-API for accounting and resource management to Guide: Enterprise Resource Planning

The bwCloud-OS provides an RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].

== Entitlement ==

=== Entitlement validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of an entitlement string.

==== Entitlement validation example 2 ====
JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2025-12-19', 'last_day_of_validation': 'inf', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 2'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>

Return: <code>{'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2026-02-01', 'last_day_of_validation': '2027-01-31', 'max_number_of_booking_units': 'inf'}</code>

'''Entitlement validation example 3'''

JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null</nowiki>"}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

== Eligibility ==

=== Eligibility rules ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' Providing this functionalities is optional and still to plan.
|}
This endpoint may be extended to allow customers to manage eligibility. By defining rules that can be applied to bwCloud-OS users when matching certain criteria. ''E.g. If the user is a memer of the medicine faculty, grant the small quota flavor.'' However, the use cases and requirements for this are yet not cleare.

* As a customer, I want a service where my local support can define rules for rolling out eligibility, such that new users from my organization gain automatic quotas.
* As a customer, I want to control who is allowed to manage and see cost centers, user groups, and personal information, such that only privileged people can grant quotas.
* As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)
* As a user, I want to see the eligibilities I am owning, such that I can plan how to debit these.

There are plenty of questions the bwCloud-OS needs to address to their customers before it gets clear what kind of centralized service actually is needed and weather it will be accepted.

=== Eligibility validation ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ Please Note:''' This endpoint is in a late testing phase and will be available soon.
|}This endpoint can be used for validating syntax and checking the interpretation of eligibility data.

'''Eligibility validation example 1'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}</code>

Return: <code>{'quota_flavor': 'large_1', 'cost_center_id': 'student', 'first_day_of_validation': '2026-01-01', 'last_day_of_validation': '2026-12-31', 'max_number_of_booking_units': 5000}</code>

'''Eligibility validation example 2'''

JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}</code>

Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

Guide: Project and Quota

2026-02-02T16:20:22Z

As1844:

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Default case. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty eligibility|empty eligibility.]]
|-
|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
!quota flavor
!'''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" |*
|*
|
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able to use compute resources. The former assigned eligibility will be free for use again.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Projects and Quota

2026-02-02T16:20:09Z

As1844:

{{InANutshell|
<li>'''(Group-)Projects''' allow shared access to resources. Project members can manage instances collaboratively. A designated '''project owner''' is required to manage the project and act as the main contact.</li>
<li>Each bwCloud-OS project has predefined '''quotas''' for vCPU, RAM, storage, networks, etc. Quota increases can be requested via the [https://bw-support.scc.kit.edu/ bwSupportPortal].</li>
<li>Quotas can be assigned to a project in multiple [[Registration#Regions|regions]].</li>
<li>Instances cannot be moved between projects directly. Use snapshots and '''volume transfer''' instead, as described
[[#Instance-Transfer|here]].</li>}}

__TOC__
= (Group) Projects =
'''➡️ More information in the guide about [[Guide: Project and Quota|Project and Quota]].'''

== In which situations is a new (group) project useful? ==


Projects allow multiple users to share and jointly manage resources within a single bwCloud-OS project. This is particularly useful for:

* '''Collaborative administration''' of servers with a '''long-term or operational''' purpose
* '''Teaching or training scenarios''' where students or participants need to collaborate
* Projects that involve users from '''multiple bwCloud-OS [[Registration#Regions|regions]]'''

Such collaboration is also supported through the use of '''access tokens''' ([[Programmatic Access and Automation#Application Credentials|Application Credentials]]).

'''📌''' '''Note:''' If the only goal is to allow multiple users to connect to the same virtual machine, you can simply add their '''SSH public keys''' to the <code>~/.ssh/authorized_keys</code> file on the VM. In that case, a new project is '''not required'''.

== What does resource administration look like in a project? ==


OpenStack uses a basic role and rights model:

* There is the role of '''“'''Administrator'''”''', which is reserved exclusively for members of the bwCloud-OS operations team.
* All regular users have the same standard user permissions.

As a result:

* Every project member can '''see all shared resources''' (instances, images, security groups, etc.).
* All members can '''create, modify, or delete''' resources.
* There are '''no internal role distinctions''' within a project — all members have '''equal rights'''.

== How can I request a new (group) project? ==

=== Gen2: ===
To create a new project, you need to submit a [https://bw-support.scc.kit.edu/ ticket] with specific information about your request. Please note:

* Only users who are already '''registered in bwCloud-OS''' can be added as '''project members'''.
* The project must have a designated owner. Please review the [[Projects and Quota#Group-Project-Owner|role]] of the '''project owner''', who is responsible for managing the project and its quota usage.
* The project name should be no longer than 16 characters.

Please use the following '''template''' when submitting your request:
<pre>SUBJECT: NEW_PROJECT
MOTIVATION: TEXT
REGION: NAME
PROJECT_NAME: NAME
OWNER_UUID: UUID
MEMBER_UUIDS: UUID, UUID, ...
NUMBER_VM: INTEGER
RAM_GB: INTEGER
VCPU: INTEGER
STORAGE_GB: INTEGER
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy</pre>'''📌''' '''Note:''' Members of the '''University of Stuttgart''' are subject to '''special rules''', which are explained in detail [[Custom Rules|here]].

=== '''Gen3:''' ===
To create a new project, you need to submit a [https://bw-support.scc.kit.edu/ ticket] with specific information about your request. Please note:
* Only users who are already '''registered in bwCloud-OS''' can be [[Projects and Quota#Can project members be changed?|added as '''project members''']].
* For granting [[Guide: Project and Quota|project quota]] you need a respective [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]].
* [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|Check for holding the eligibility]].
* The owner of the eligibility will become the project owner.

Please use the following '''template''' when submitting your request:
<pre>SUBJECT: "Request new project"
MOTIVATION: TEXT
REGION: NAME
MEMBER_UUIDS: UUID, UUID, ...
QUOTA_FLAVOR: NAME
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy</pre>

== Why is it necessary to specify a project owner? ==


The person designated as the '''project owner''' is needed for several important reasons:

# '''Billing and accountability''': [[Guide: Charging|Cost allocation]] is introduced with bwCloud-OS (Gen3). Any billing or formal communication related to the project will be directed to the project owner's institution.
# '''Primary contact for the bwCloud-OS team''': The project owner acts as the main contact person for the bwCloud-OS team — for operational issues, incidents, and support inquiries.
# '''User and membership management''': The owner is responsible for managing project membership. We can only accept requests to add or remove members from the owner (or a designated replacement), since all project members have the same technical permissions. Otherwise, we cannot verify who has the authority to manage membership.
The project owner is always a member of the project.

== Can the project owner be a functional or shared account? ==


No. All accounts and identifiers used in bwCloud-OS — including those for '''project owners''' and '''project members''' — must be assigned to '''individual, identifiable persons'''.

== How can I change the eligibility and ownership of a project? ==

=== Gen2 ===
If you currently own the project, you can request this via a [https://bw-support.scc.kit.edu/ ticket]. The new owner needs to respond within the ticket as well.

=== Gen3 ===
To request the change of the [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]] assigned to the project, please provide the following information in a [https://bw-support.scc.kit.edu/ Ticket]. Please note:

* [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|Check for holding the new eligibility]].
* The owner of the new eligibility will be the (new) owner of the project.
* If you currently own the project and are holding additional [[Guide: Entitlement & Eligibility|eligibility]], you can request this. If a second user is holding the new eligibility, the second user needs to respond within the ticket as well.

Please use the following '''template''' when submitting your request:<pre>
SUBJECT: "Change eligibility"
MOTIVATION: TEXT
OWNER_UUID: UUID
PROJECT_UUID: UUID
QUOTA_FLAVOR: NAME
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy
</pre>The [[Guide: Project and Quota#Example project and eligibility 1|Project-Eligibiity link]] will be updated afterward.

== Can project members be changed? ==


Yes, members of a project can be '''added or removed''' at any time. '''Only the''' '''project owner''' is authorized to request changes to the project membership.

To request member changes, please submit a [https://bw-support.scc.kit.edu/ support ticket] and provide the following information using this '''template''':<pre>
SUBJECT: MEMBER_PROJECT
NEW_OWNER: UUID
PROJECT: UUID
MEMBERS_ADD: UUID, UUID, ...
MEMBERS_REMOVE: UUID, UUID, ...
</pre>

== How can I switch between projects? ==


A user can be a member of multiple projects, and projects can have quotas in multiple bwCloud-OS [[Registration#Regions|regions]].

To switch between projects and regions, use the project/region selector button located at the top left of the '''[https://portal.bw-cloud.org/ Dashboard]'''. This allows you to choose the target project and corresponding region for your current session.
[[File:Project selection.png|center|thumb|551x551px]]

== Can I move an instance to another project? ==


Instances cannot be directly moved between projects. However, you can use the following workaround, provided the target project has sufficient available quota:

'''In the Source Project:'''
# Create a '''snapshot''' of the instance. The snapshot will appear under '''Images'''.
# From the snapshot, create a '''volume'''. The volume will appear under '''Volumes'''.
# Create a '''transfer''' for the volume and record the '''Transfer ID''' and '''Authorization Key'''.
'''In the Target Project:'''
# Go to '''Volumes''' and select '''Accept Transfer'''.
# Enter the recorded '''Transfer ID''' and '''Authorization Key'''. The volume will now appear under '''Volumes'''.
# Convert or upload the volume to an '''image'''. The image will appear under '''Images'''''. This process may take some time''.
# Launch a new instance from the image in the target project.

= Project Quota =
'''➡️ More information in the guide about [[Guide: Project and Quota|Project and Quota]].'''

== How can I request an additional quota? ==

=== '''Gen2:''' ===
To request additional quota, please provide the following information and submit your request via the [https://bw-support.scc.kit.edu/ Support Portal] using the following '''template''':

<pre>
SUBJECT: NEW_QUOTA
MOTIVATION: TEXT
USER_UUID: UUID
PROJECT_UUID: UUID
NUMBER_VM: INTEGER
RAM_GB: INTEGER
VCPU: INTEGER
STORAGE_GB: INTEGER
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy
</pre>📌 '''Note:''' The values you provide must represent the '''total desired quota''' for your project '''after''' the increase, '''not''' the additional amount to be added on top of your current quota.

=== Gen3: ===
To request additional quota please request the [[Projects and Quota#How can I change the eligibility and ownership of a project?|change of the eligibility]]. Please note:

* For the [[Guide: Project and Quota|project quota]] you need a respective [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]].

Guide: Project and Quota

2026-02-02T16:17:08Z

As1844:

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Default case. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty eligibility|empty eligibility.]]
|-
|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
!quota flavor
!'''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" |*
|*
|
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able use compute resources.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Guide: Project and Quota

2026-02-02T16:12:57Z

As1844:

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

== Project and eligibility ==
For quota project to be assigned to a project, this need to be granted in advance by assigning an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] to the owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Default case. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty eligibility|empty eligibility.]]
|-
|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
!quota flavor
!'''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" |*
|*
|
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able use compute resources.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Registration

2026-02-02T16:04:52Z

As1844:

{{InANutshell|
<li>Access to bwCloud-OS requires an active account from a '''bwIDM'''-participating institution.</li>
<li>Your account must include a valid '''entitlement''', assigned by your '''home institution'''. This is usually automatic. If it is missing (see [[Registration#My-Entitlements|here]]), contact your institution’s IT support. The bwCloud-OS team cannot assign entitlements.</li>
<li>The entitlement carries information about the eligibility. An '''eligibility''' is the privilege to consume resources within a project and therefore for generating costs.</li>
<li>Log in once to the [https://portal.bw-cloud.org/ '''Dashboard'''] to activate your profile. Setup is automated via bwIDM.</li>
<li>After login, select your '''region''' as described [[Registration#Region-Selection|here]] to begin using bwCloud-OS.</li>}}

__TOC__

= Identity Management =


'''➡️ More information in the guide about [[Guide: Registration|Registration]].'''

== What is "bwIDM" and why does it know me? ==


Every member of a higher education institution in Baden-Württemberg (university, college, PH, HAW, etc.) has a personal account for accessing the IT services provided by their institution. If the institution participates in the federated identity management system [https://www.bwidm.de/ '''bwIDM'''], its members can also apply for additional IT services offered by other participating institutions.

To allow external IT services to identify users, certain personal data is transmitted via bwIDM to these services during registration and use of the service. Federated identity management ensures, through a model of mutual trust, that the external service can verify the user’s affiliation with their institution — confirming that the account is valid and the user is officially recognized. Within the bwIDM Federation, participating institutions have agreed on a minimum set of personal data that is transmitted to external IT services. This includes standard attributes such as <code>eduPersonPrincipalName</code>, <code>mail</code>, <code>givenName</code> or <code>eduPersonEntitlement</code>.

== What happens during the registration for the bwCloud-OS service? ==

During the registration on bwIDM for the bwCloud-OS service, the following steps are streamlined:

# A user registers himself*herself.
# bwIDM requests the creation of a user account by the bwCloud-OS and forwards a set of user data.
# The bwCloud-OS parses the user data, including given [[Guide: Entitlement & Eligibility|entitlements]].
# Based on these data, a user account and a start [[Projects and Quota|project]] is created. The [[Guide: Entitlement & Eligibility#Quota flavors|quota flavor]] given in the entitlement defines the project quota. If more than one [[Guide: Entitlement & Eligibility#Quota Entitlements|quota eligibilities]] are given, a random one is chosen. [[Projects and Quota#Change-Eligibility|The eligibility can later on be changed.]]

= Entitlement and Eligibility =


'''📌 Note:''' The bwCloud(-OS) entitlement model is currently being restructured and subject to change.

'''➡️ More information in the guide about [[Guide: Entitlement & Eligibility|Entitlement & Eligibility]].'''

== What is the difference between flavor, quota, and quota flavors? ==

* [[Instances (VMs)#Flavors|Flavor]] (or VM flavor) is a defined set of resources (core, RAM, storage) that can be chosen as the size of an instance.
* [[Projects and Quota#Quota|Quota]] (or project quota) is the amount of resources (core, RAM, storage, network, volume, etc.) a project can consume or bind.
* [[Guide: Entitlement & Eligibility#Quota flavors|Quota flavors]] is a defined set of project quotas that can be chosen as the size of a project.

== What is the difference between entitlement and eligibility? ==

* [[Guide: Entitlement & Eligibility#Eligibility|Eligibility]] defines the permission for a user to consume resources in the bwCloud-OS. Inside the bwCloud-OS is only interpreting eligibilities.
* [[Guide: Entitlement & Eligibility#Entitlement URN structure|Entitlement]] is classified into two types:
** The [[Guide: Entitlement & Eligibility#Quota Entitlements|access entitlement]] defines the privilege for using the bwCloud-OS.
** [[Guide: Entitlement & Eligibility#Quota Entitlements|Quota entitlements]] containing an eligibility.

== As a customer (institute): What do I need to prepare my IDM for the bwCloud-OS Gen3? ==

* You need to set the [[Guide: Entitlement & Eligibility#Access Entitlement|access entitlement]] for all members.
* Every member needs a [[Guide: Entitlement & Eligibility#Quota flavors|quota flavors]] to start using. It may be great to cover 95% of your use cases with this.
* For the other 5%, the power users, extra entitlements must be managed.

== Is a centralized service planned to manage eligibility directly in the bwCloud-OS? ==
Not yet. This sounds like a complex service. There are plenty of [[Guide: Entitlement & Eligibility#Central eligibility platform|questions for this central service]] we have to ask in advance.

== What entitlement do I have to become a member of an existing project? ==
There is no entitlement required to become a member of an existing project. [[Projects and Quota#Can project members be changed?|New project members can be added anytime.]]

== Can I use the same entitlement or eligibility for several projects? ==
No. A user with his eligibility can only be assigned to one project, <code>{0,1}:1</code> mapping.

== I have an entitlement. How can I get a project with a quota? ==
Only once, during the registration of a new user, is a (start-)project automatically created from a given eligibility. Afterward, a user needs to [[Projects and Quota#How can I request a new (group) project?|request a new project]].

== How can I find out which entitlements I am owning? ==


To inspect your personal data, open the [https://login.bwidm.de/user/index.xhtml bwIDM] services and switch to the rider ''Shibboleth.'' Under <code><nowiki>urn:oid:1.3.6.1.4.1.5923.1.1.1.7</nowiki></code> (<code>eduPersonEntitlement</code>) you can see your entitlement.

== What should I do if my account has no bwCloud-OS entitlement assigned? ==


The assignment of entitlements is exclusively managed by your home institution. The bwCloud-OS team does '''not''' have the authority to add or remove entitlements on user accounts. If your account lacks the necessary entitlement, please contact your institution’s central IT service department or service desk.

== When will the additional eligibility features be supported? ==
We are aware that you wish to budget, control, and manage your expenses. Therefore, we designed these features. However, currently we need to get used to a large set of new processes. If the bwCloud-OS accomplishes this, additional features will be supported.

= Regions =

== What does "region" mean in bwCloud-OS? ==


In bwCloud-OS, a '''region''' refers to one of the four operating sites: '''Freiburg''', '''Karlsruhe''', '''Mannheim''', and '''Ulm'''. Each region runs its own infrastructure but is accessible through a shared interface ([https://portal.bw-cloud.org/ Dashboard]).

Resources such as virtual machines (VMs, instances), networks, and storage are bound to the region in which they are created. For example, an instance launched in the Mannheim region will receive an IP address from Mannheim’s specific IP range(s) — this address cannot be transferred to another region.

You can switch between regions in the Dashboard interface as described [[Registration#Region-Selection|here]].

== What is my "home region"? ==


In bwCloud-OS, each user is initially assigned a '''home region''' during account setup. For users from one of the four operating sites (Freiburg, Karlsruhe, Mannheim, Ulm), this assignment is straightforward. For users from other institutions, the assignment is based on the network topology of [https://www.belwue.de/ BelWue] — aiming to route each user to the nearest operating site for optimal connectivity. However, you can [[Projects and Quota#Group-Project-Application|apply for a project]] with resources (also) in other regions.

A table showing the current home region assignments can be found [[Regions|here]].

== Where do I select the region in the Dashboard? ==


You can select a region from the drop-down menu located on the left side of the top navigation bar in the [https://portal.bw-cloud.org/ Dashboard]. The currently active region is marked with a checkmark. Simply click on a different region in the list to switch to it.[[File:Region selection.png|center|thumb|722x722px]]

File:Example project eligibility.drawio.png

2026-02-02T15:45:51Z

As1844:

Example for project and eligibility relation

Guide: Project and Quota

2026-02-02T12:11:09Z

As1844:

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

== Project and eligibilities ==
For quota project to be assigned to a project, this need to be granted in advance by assigning an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] to the owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.

== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Default case. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty eligibility|empty eligibility.]]
|-
|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
!quota flavor
!'''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" |*
|*
|
|}

Projects and Quota

2026-02-02T12:10:57Z

As1844:

{{InANutshell|
<li>'''(Group-)Projects''' allow shared access to resources. Project members can manage instances collaboratively. A designated '''project owner''' is required to manage the project and act as the main contact.</li>
<li>Each bwCloud-OS project has predefined '''quotas''' for vCPU, RAM, storage, networks, etc. Quota increases can be requested via the [https://bw-support.scc.kit.edu/ bwSupportPortal].</li>
<li>Quotas can be assigned to a project in multiple [[Registration#Regions|regions]].</li>
<li>Instances cannot be moved between projects directly. Use snapshots and '''volume transfer''' instead, as described
[[#Instance-Transfer|here]].</li>}}

__TOC__
= (Group) Projects =
'''➡️ More information in the guide about [[Guide: Project and Quota|Project and Quota]].'''

== In which situations is a new (group) project useful? ==


Projects allow multiple users to share and jointly manage resources within a single bwCloud-OS project. This is particularly useful for:

* '''Collaborative administration''' of servers with a '''long-term or operational''' purpose
* '''Teaching or training scenarios''' where students or participants need to collaborate
* Projects that involve users from '''multiple bwCloud-OS [[Registration#Regions|regions]]'''

Such collaboration is also supported through the use of '''access tokens''' ([[Programmatic Access and Automation#Application Credentials|Application Credentials]]).

'''📌''' '''Note:''' If the only goal is to allow multiple users to connect to the same virtual machine, you can simply add their '''SSH public keys''' to the <code>~/.ssh/authorized_keys</code> file on the VM. In that case, a new project is '''not required'''.

== What does resource administration look like in a project? ==


OpenStack uses a basic role and rights model:

* There is the role of '''“'''Administrator'''”''', which is reserved exclusively for members of the bwCloud-OS operations team.
* All regular users have the same standard user permissions.

As a result:

* Every project member can '''see all shared resources''' (instances, images, security groups, etc.).
* All members can '''create, modify, or delete''' resources.
* There are '''no internal role distinctions''' within a project — all members have '''equal rights'''.

== How can I request a new (group) project? ==

=== Gen2: ===
To create a new project, you need to submit a [https://bw-support.scc.kit.edu/ ticket] with specific information about your request. Please note:

* Only users who are already '''registered in bwCloud-OS''' can be added as '''project members'''.
* The project must have a designated owner. Please review the [[Projects and Quota#Group-Project-Owner|role]] of the '''project owner''', who is responsible for managing the project and its quota usage.
* The project name should be no longer than 16 characters.

Please use the following '''template''' when submitting your request:
<pre>SUBJECT: NEW_PROJECT
MOTIVATION: TEXT
REGION: NAME
PROJECT_NAME: NAME
OWNER_UUID: UUID
MEMBER_UUIDS: UUID, UUID, ...
NUMBER_VM: INTEGER
RAM_GB: INTEGER
VCPU: INTEGER
STORAGE_GB: INTEGER
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy</pre>'''📌''' '''Note:''' Members of the '''University of Stuttgart''' are subject to '''special rules''', which are explained in detail [[Custom Rules|here]].

=== '''Gen3:''' ===
To create a new project, you need to submit a [https://bw-support.scc.kit.edu/ ticket] with specific information about your request. Please note:
* Only users who are already '''registered in bwCloud-OS''' can be [[Projects and Quota#Can project members be changed?|added as '''project members''']].
* For granting [[Guide: Project and Quota|project quota]] you need a respective [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]].
* [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|Check for holding the eligibility]].
* The owner of the eligibility will become the project owner.

Please use the following '''template''' when submitting your request:
<pre>SUBJECT: "Request new project"
MOTIVATION: TEXT
REGION: NAME
MEMBER_UUIDS: UUID, UUID, ...
QUOTA_FLAVOR: NAME
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy</pre>

== Why is it necessary to specify a project owner? ==


The person designated as the '''project owner''' is needed for several important reasons:

# '''Billing and accountability''': [[Guide: Charging|Cost allocation]] is introduced with bwCloud-OS (Gen3). Any billing or formal communication related to the project will be directed to the project owner's institution.
# '''Primary contact for the bwCloud-OS team''': The project owner acts as the main contact person for the bwCloud-OS team — for operational issues, incidents, and support inquiries.
# '''User and membership management''': The owner is responsible for managing project membership. We can only accept requests to add or remove members from the owner (or a designated replacement), since all project members have the same technical permissions. Otherwise, we cannot verify who has the authority to manage membership.
The project owner is always a member of the project.

== Can the project owner be a functional or shared account? ==


No. All accounts and identifiers used in bwCloud-OS — including those for '''project owners''' and '''project members''' — must be assigned to '''individual, identifiable persons'''.

== How can I change the eligibility and ownership of a project? ==

=== Gen2 ===
If you currently own the project, you can request this via a [https://bw-support.scc.kit.edu/ ticket]. The new owner needs to respond within the ticket as well.

=== Gen3 ===
To request the change of the [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]] assigned to the project, please provide the following information in a [https://bw-support.scc.kit.edu/ Ticket]. Please note:

* [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|Check for holding the new eligibility]].
* The owner of the new eligibility will be the (new) owner of the project.
* If you currently own the project and are holding additional [[Guide: Entitlement & Eligibility|eligibility]], you can request this. If a second user is holding the new eligibility, the second user needs to respond within the ticket as well.

Please use the following '''template''' when submitting your request:<pre>
SUBJECT: "Change eligibility"
MOTIVATION: TEXT
OWNER_UUID: UUID
PROJECT_UUID: UUID
QUOTA_FLAVOR: NAME
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy
</pre>'''➡️ More information in the guide about [[Guide: Project and Quota|Project and Quota]].'''

== Can project members be changed? ==


Yes, members of a project can be '''added or removed''' at any time. '''Only the''' '''project owner''' is authorized to request changes to the project membership.

To request member changes, please submit a [https://bw-support.scc.kit.edu/ support ticket] and provide the following information using this '''template''':<pre>
SUBJECT: MEMBER_PROJECT
NEW_OWNER: UUID
PROJECT: UUID
MEMBERS_ADD: UUID, UUID, ...
MEMBERS_REMOVE: UUID, UUID, ...
</pre>

== How can I switch between projects? ==


A user can be a member of multiple projects, and projects can have quotas in multiple bwCloud-OS [[Registration#Regions|regions]].

To switch between projects and regions, use the project/region selector button located at the top left of the '''[https://portal.bw-cloud.org/ Dashboard]'''. This allows you to choose the target project and corresponding region for your current session.
[[File:Project selection.png|center|thumb|551x551px]]

== Can I move an instance to another project? ==


Instances cannot be directly moved between projects. However, you can use the following workaround, provided the target project has sufficient available quota:

'''In the Source Project:'''
# Create a '''snapshot''' of the instance. The snapshot will appear under '''Images'''.
# From the snapshot, create a '''volume'''. The volume will appear under '''Volumes'''.
# Create a '''transfer''' for the volume and record the '''Transfer ID''' and '''Authorization Key'''.
'''In the Target Project:'''
# Go to '''Volumes''' and select '''Accept Transfer'''.
# Enter the recorded '''Transfer ID''' and '''Authorization Key'''. The volume will now appear under '''Volumes'''.
# Convert or upload the volume to an '''image'''. The image will appear under '''Images'''''. This process may take some time''.
# Launch a new instance from the image in the target project.

= Project Quota =


Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== How can I request an additional quota? ==

=== '''Gen2:''' ===
To request additional quota, please provide the following information and submit your request via the [https://bw-support.scc.kit.edu/ Support Portal] using the following '''template''':

<pre>
SUBJECT: NEW_QUOTA
MOTIVATION: TEXT
USER_UUID: UUID
PROJECT_UUID: UUID
NUMBER_VM: INTEGER
RAM_GB: INTEGER
VCPU: INTEGER
STORAGE_GB: INTEGER
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy
</pre>📌 '''Note:''' The values you provide must represent the '''total desired quota''' for your project '''after''' the increase, '''not''' the additional amount to be added on top of your current quota.

=== Gen3: ===
To request additional quota please request the [[Projects and Quota#How can I change the eligibility and ownership of a project?|change of the eligibility]]. Please note:

* For the [[Guide: Project and Quota|project quota]] you need a respective [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]].

Projects and Quota

2026-02-02T11:28:16Z

As1844:

{{InANutshell|
<li>'''(Group-)Projects''' allow shared access to resources. Project members can manage instances collaboratively. A designated '''project owner''' is required to manage the project and act as the main contact.</li>
<li>Each bwCloud-OS project has predefined '''quotas''' for vCPU, RAM, storage, networks, etc. Quota increases can be requested via the [https://bw-support.scc.kit.edu/ bwSupportPortal].</li>
<li>Quotas can be assigned to a project in multiple [[Registration#Regions|regions]].</li>
<li>Instances cannot be moved between projects directly. Use snapshots and '''volume transfer''' instead, as described
[[#Instance-Transfer|here]].</li>}}

__TOC__
= (Group) Projects =

== In which situations is a new (group) project useful? ==


Projects allow multiple users to share and jointly manage resources within a single bwCloud-OS project. This is particularly useful for:

* '''Collaborative administration''' of servers with a '''long-term or operational''' purpose
* '''Teaching or training scenarios''' where students or participants need to collaborate
* Projects that involve users from '''multiple bwCloud-OS [[Registration#Regions|regions]]'''

Such collaboration is also supported through the use of '''access tokens''' ([[Programmatic Access and Automation#Application Credentials|Application Credentials]]).

'''📌''' '''Note:''' If the only goal is to allow multiple users to connect to the same virtual machine, you can simply add their '''SSH public keys''' to the <code>~/.ssh/authorized_keys</code> file on the VM. In that case, a new project is '''not required'''.

== What does resource administration look like in a project? ==


OpenStack uses a basic role and rights model:

* There is the role of '''“'''Administrator'''”''', which is reserved exclusively for members of the bwCloud-OS operations team.
* All regular users have the same standard user permissions.

As a result:

* Every project member can '''see all shared resources''' (instances, images, security groups, etc.).
* All members can '''create, modify, or delete''' resources.
* There are '''no internal role distinctions''' within a project — all members have '''equal rights'''.

== How can I request a new (group) project? ==

=== Gen2: ===
To create a new project, you need to submit a [https://bw-support.scc.kit.edu/ ticket] with specific information about your request. Please note:

* Only users who are already '''registered in bwCloud-OS''' can be added as '''project members'''.
* The project must have a designated owner. Please review the [[Projects and Quota#Group-Project-Owner|role]] of the '''project owner''', who is responsible for managing the project and its quota usage.
* The project name should be no longer than 16 characters.

Please use the following '''template''' when submitting your request:
<pre>SUBJECT: NEW_PROJECT
MOTIVATION: TEXT
REGION: NAME
PROJECT_NAME: NAME
OWNER_UUID: UUID
MEMBER_UUIDS: UUID, UUID, ...
NUMBER_VM: INTEGER
RAM_GB: INTEGER
VCPU: INTEGER
STORAGE_GB: INTEGER
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy</pre>'''📌''' '''Note:''' Members of the '''University of Stuttgart''' are subject to '''special rules''', which are explained in detail [[Custom Rules|here]].

=== '''Gen3:''' ===
To create a new project, you need to submit a [https://bw-support.scc.kit.edu/ ticket] with specific information about your request. Please note:
* Only users who are already '''registered in bwCloud-OS''' can be [[Projects and Quota#Can project members be changed?|added as '''project members''']].
* For the [[Guide: Project and Quota|quota flavor]] you need a respective [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]].
* The owner of the eligibility will become the project owner.

Please use the following '''template''' when submitting your request:
<pre>SUBJECT: "Request new project"
MOTIVATION: TEXT
REGION: NAME
MEMBER_UUIDS: UUID, UUID, ...
QUOTA_FLAVOR: NAME
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy</pre>

== Why is it necessary to specify a project owner? ==


The person designated as the '''project owner''' is needed for several important reasons:

# '''Billing and accountability''': [[Guide: Charging|Cost allocation]] is introduced with bwCloud-OS (Gen3). Any billing or formal communication related to the project will be directed to the project owner's institution.
# '''Primary contact for the bwCloud-OS team''': The project owner acts as the main contact person for the bwCloud-OS team — for operational issues, incidents, and support inquiries.
# '''User and membership management''': The owner is responsible for managing project membership. We can only accept requests to add or remove members from the owner (or a designated replacement), since all project members have the same technical permissions. Otherwise, we cannot verify who has the authority to manage membership.
The project owner is always a member of the project.

== Can the project owner be a functional or shared account? ==


No. All accounts and identifiers used in bwCloud-OS — including those for '''project owners''' and '''project members''' — must be assigned to '''individual, identifiable persons'''.

== How can I change the eligibility and ownership of a project? ==

=== Gen2 ===
If you currently own the project, you can request this via a [https://bw-support.scc.kit.edu/ ticket]. The new owner needs to respond within the ticket as well.

=== Gen3 ===
To request the change of the [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]] assigned to the project, please provide the following information in a [https://bw-support.scc.kit.edu/ Ticket]. Please note:

* The owner of the new eligibility will be the (new) owner of the project.
* If you currently own the project and are holding additional [[Guide: Entitlement & Eligibility|eligibility]], you can request this. If a second user is holding the new eligibility, the second user needs to respond within the ticket as well.
* [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|Check for holding the new eligibility]].

Please use the following '''template''' when submitting your request:<pre>
SUBJECT: "Change eligibility"
MOTIVATION: TEXT
OWNER_UUID: UUID
PROJECT_UUID: UUID
QUOTA_FLAVOR: NAME
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy
</pre>

== Can project members be changed? ==


Yes, members of a project can be '''added or removed''' at any time. '''Only the''' '''project owner''' is authorized to request changes to the project membership.

To request member changes, please submit a [https://bw-support.scc.kit.edu/ support ticket] and provide the following information using this '''template''':<pre>
SUBJECT: MEMBER_PROJECT
NEW_OWNER: UUID
PROJECT: UUID
MEMBERS_ADD: UUID, UUID, ...
MEMBERS_REMOVE: UUID, UUID, ...
</pre>

== How can I switch between projects? ==


A user can be a member of multiple projects, and projects can have quotas in multiple bwCloud-OS [[Registration#Regions|regions]].

To switch between projects and regions, use the project/region selector button located at the top left of the '''[https://portal.bw-cloud.org/ Dashboard]'''. This allows you to choose the target project and corresponding region for your current session.
[[File:Project selection.png|center|thumb|551x551px]]

== Can I move an instance to another project? ==


Instances cannot be directly moved between projects. However, you can use the following workaround, provided the target project has sufficient available quota:

'''In the Source Project:'''
# Create a '''snapshot''' of the instance. The snapshot will appear under '''Images'''.
# From the snapshot, create a '''volume'''. The volume will appear under '''Volumes'''.
# Create a '''transfer''' for the volume and record the '''Transfer ID''' and '''Authorization Key'''.
'''In the Target Project:'''
# Go to '''Volumes''' and select '''Accept Transfer'''.
# Enter the recorded '''Transfer ID''' and '''Authorization Key'''. The volume will now appear under '''Volumes'''.
# Convert or upload the volume to an '''image'''. The image will appear under '''Images'''''. This process may take some time''.
# Launch a new instance from the image in the target project.

= Project Quota =


Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== How can I request an additional quota? ==

=== '''Gen2:''' ===
To request additional quota, please provide the following information and submit your request via the [https://bw-support.scc.kit.edu/ Support Portal] using the following '''template''':

<pre>
SUBJECT: NEW_QUOTA
MOTIVATION: TEXT
USER_UUID: UUID
PROJECT_UUID: UUID
NUMBER_VM: INTEGER
RAM_GB: INTEGER
VCPU: INTEGER
STORAGE_GB: INTEGER
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy
</pre>📌 '''Note:''' The values you provide must represent the '''total desired quota''' for your project '''after''' the increase, '''not''' the additional amount to be added on top of your current quota.

=== Gen3: ===
To request additional quota please request the [[Projects and Quota#How can I change the eligibility and ownership of a project?|change of the eligibility]]. Please note:

* For the [[Guide: Project and Quota|project quota]] you need a respective [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]].

Projects and Quota

2026-02-02T11:25:28Z

As1844:

{{InANutshell|
<li>'''(Group-)Projects''' allow shared access to resources. Project members can manage instances collaboratively. A designated '''project owner''' is required to manage the project and act as the main contact.</li>
<li>Each bwCloud-OS project has predefined '''quotas''' for vCPU, RAM, storage, networks, etc. Quota increases can be requested via the [https://bw-support.scc.kit.edu/ bwSupportPortal].</li>
<li>Quotas can be assigned to a project in multiple [[Registration#Regions|regions]].</li>
<li>Instances cannot be moved between projects directly. Use snapshots and '''volume transfer''' instead, as described
[[#Instance-Transfer|here]].</li>}}

__TOC__
= (Group) Projects =

== In which situations is a new (group) project useful? ==


Projects allow multiple users to share and jointly manage resources within a single bwCloud-OS project. This is particularly useful for:

* '''Collaborative administration''' of servers with a '''long-term or operational''' purpose
* '''Teaching or training scenarios''' where students or participants need to collaborate
* Projects that involve users from '''multiple bwCloud-OS [[Registration#Regions|regions]]'''

Such collaboration is also supported through the use of '''access tokens''' ([[Programmatic Access and Automation#Application Credentials|Application Credentials]]).

'''📌''' '''Note:''' If the only goal is to allow multiple users to connect to the same virtual machine, you can simply add their '''SSH public keys''' to the <code>~/.ssh/authorized_keys</code> file on the VM. In that case, a new project is '''not required'''.

== What does resource administration look like in a project? ==


OpenStack uses a basic role and rights model:

* There is the role of '''“'''Administrator'''”''', which is reserved exclusively for members of the bwCloud-OS operations team.
* All regular users have the same standard user permissions.

As a result:

* Every project member can '''see all shared resources''' (instances, images, security groups, etc.).
* All members can '''create, modify, or delete''' resources.
* There are '''no internal role distinctions''' within a project — all members have '''equal rights'''.

== How can I request a new (group) project? ==

=== Gen2: ===
To create a new project, you need to submit a [https://bw-support.scc.kit.edu/ ticket] with specific information about your request. Please note:

* Only users who are already '''registered in bwCloud-OS''' can be added as '''project members'''.
* The project must have a designated owner. Please review the [[Projects and Quota#Group-Project-Owner|role]] of the '''project owner''', who is responsible for managing the project and its quota usage.
* The project name should be no longer than 16 characters.

Please use the following '''template''' when submitting your request:
<pre>SUBJECT: NEW_PROJECT
MOTIVATION: TEXT
REGION: NAME
PROJECT_NAME: NAME
OWNER_UUID: UUID
MEMBER_UUIDS: UUID, UUID, ...
NUMBER_VM: INTEGER
RAM_GB: INTEGER
VCPU: INTEGER
STORAGE_GB: INTEGER
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy</pre>'''📌''' '''Note:''' Members of the '''University of Stuttgart''' are subject to '''special rules''', which are explained in detail [[Custom Rules|here]].

=== '''Gen3:''' ===
To create a new project, you need to submit a [https://bw-support.scc.kit.edu/ ticket] with specific information about your request. Please note:
* Only users who are already '''registered in bwCloud-OS''' can be [[Projects and Quota#Can project members be changed?|added as '''project members''']].
* For the [[Guide: Project and Quota|quota flavor]] you need a respective [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]].
* The owner of the eligibility will become the project owner.

Please use the following '''template''' when submitting your request:
<pre>SUBJECT: "Request new project"
MOTIVATION: TEXT
REGION: NAME
MEMBER_UUIDS: UUID, UUID, ...
QUOTA_FLAVOR: NAME
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy</pre>

== Why is it necessary to specify a project owner? ==


The person designated as the '''project owner''' is needed for several important reasons:

# '''Billing and accountability''': [[Guide: Charging|Cost allocation]] is introduced with bwCloud-OS (Gen3). Any billing or formal communication related to the project will be directed to the project owner's institution.
# '''Primary contact for the bwCloud-OS team''': The project owner acts as the main contact person for the bwCloud-OS team — for operational issues, incidents, and support inquiries.
# '''User and membership management''': The owner is responsible for managing project membership. We can only accept requests to add or remove members from the owner (or a designated replacement), since all project members have the same technical permissions. Otherwise, we cannot verify who has the authority to manage membership.
The project owner is always a member of the project.

== Can the project owner be a functional or shared account? ==


No. All accounts and identifiers used in bwCloud-OS — including those for '''project owners''' and '''project members''' — must be assigned to '''individual, identifiable persons'''.

== How can I change the eligibility and ownership of a project? ==

=== Gen2 ===
If you currently own the project, you can request this via a [https://bw-support.scc.kit.edu/ ticket]. The new owner needs to respond within the ticket as well.

=== Gen3 ===
To request the change of the [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]] assigned to the project, please provide the following information in a [https://bw-support.scc.kit.edu/ Ticket]. Please note:

* The owner of the new eligibility will be the (new) owner of the project.
* If you currently own the project and are holding additional [[Guide: Entitlement & Eligibility|eligibility]], you can request this. If a second user is holding the new eligibility, the second user needs to respond within the ticket as well.

Please use the following '''template''' when submitting your request:<pre>
SUBJECT: "Change eligibility"
MOTIVATION: TEXT
OWNER_UUID: UUID
PROJECT_UUID: UUID
QUOTA_FLAVOR: NAME
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy
</pre>

== Can project members be changed? ==


Yes, members of a project can be '''added or removed''' at any time. '''Only the''' '''project owner''' is authorized to request changes to the project membership.

To request member changes, please submit a [https://bw-support.scc.kit.edu/ support ticket] and provide the following information using this '''template''':<pre>
SUBJECT: MEMBER_PROJECT
NEW_OWNER: UUID
PROJECT: UUID
MEMBERS_ADD: UUID, UUID, ...
MEMBERS_REMOVE: UUID, UUID, ...
</pre>

== How can I switch between projects? ==


A user can be a member of multiple projects, and projects can have quotas in multiple bwCloud-OS [[Registration#Regions|regions]].

To switch between projects and regions, use the project/region selector button located at the top left of the '''[https://portal.bw-cloud.org/ Dashboard]'''. This allows you to choose the target project and corresponding region for your current session.
[[File:Project selection.png|center|thumb|551x551px]]

== Can I move an instance to another project? ==


Instances cannot be directly moved between projects. However, you can use the following workaround, provided the target project has sufficient available quota:

'''In the Source Project:'''
# Create a '''snapshot''' of the instance. The snapshot will appear under '''Images'''.
# From the snapshot, create a '''volume'''. The volume will appear under '''Volumes'''.
# Create a '''transfer''' for the volume and record the '''Transfer ID''' and '''Authorization Key'''.
'''In the Target Project:'''
# Go to '''Volumes''' and select '''Accept Transfer'''.
# Enter the recorded '''Transfer ID''' and '''Authorization Key'''. The volume will now appear under '''Volumes'''.
# Convert or upload the volume to an '''image'''. The image will appear under '''Images'''''. This process may take some time''.
# Launch a new instance from the image in the target project.

= Project Quota =


Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== How can I request an additional quota? ==

=== '''Gen2:''' ===
To request additional quota, please provide the following information and submit your request via the [https://bw-support.scc.kit.edu/ Support Portal] using the following '''template''':

<pre>
SUBJECT: NEW_QUOTA
MOTIVATION: TEXT
USER_UUID: UUID
PROJECT_UUID: UUID
NUMBER_VM: INTEGER
RAM_GB: INTEGER
VCPU: INTEGER
STORAGE_GB: INTEGER
SPECIAL_QUOTA: TEXT
CUT_OFF_DATE: dd.mm.yyyy
</pre>📌 '''Note:''' The values you provide must represent the '''total desired quota''' for your project '''after''' the increase, '''not''' the additional amount to be added on top of your current quota.

=== Gen3: ===
To request additional quota please request the [[Projects and Quota#How can I change the eligibility and ownership of a project?|change of the eligibility]]. Please note:

* For the [[Guide: Project and Quota|project quota]] you need a respective [[Entitlement & Eligibility#How can I find out which entitlements I am owning?|eligibility]].

Guide: Entitlement & Eligibility

2026-02-02T11:05:12Z

As1844: /* Quota flavors */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

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]]).

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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 ==
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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>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 ==

=== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

=== Eligibility examples ===

==== Example eligibility 1 ====
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|Example for eligibility cost centers|600x600px|left]]

Guide: Entitlement & Eligibility

2026-02-02T11:03:34Z

As1844: /* Quota flavors */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This page is currently under development but kept up to date.
|}
{| class="mw-message-box mw-message-box-info"
| 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 [[Registration#Entitlements-bwCloud-OS|Registration & Entitlements]].'''

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]]).

* Entitlements are strings assigned to a user carrying information about his/her privileges.
* 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 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 <code>eduPersonEntitlement</code> 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.

__TOC__

== Motivation ==
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 ===
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 ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.

=== Charging ===
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 [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|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.
* 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.

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

* [[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.

=== 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 ==
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):
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:ELIGIBILITY</nowiki>
bzw.
<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 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 [[Registration|register]] for the bwCloud-OS.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:access</nowiki>
{| class="wikitable"
!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 ===
A quota flavor 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 [[Guide: Project and Quota#List of quota flavors|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 ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ 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 <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.

=== Constraints ===

==== First day of validation ====
{| class="mw-message-box mw-message-box-warning"
| 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 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 ====
{| class="mw-message-box mw-message-box-warning"
| 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 eligibility is forever valid.

==== Maximal number of booking units ====
{| class="mw-message-box mw-message-box-warning"
| 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>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 ==

=== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = inf

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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 <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:bwidm:bwcloud-os:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = student
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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''.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group</nowiki>:'''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 = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

==== 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.
<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = <nowiki>{{today}}</nowiki>
last_day_of_validation = inf
max_booking_units = 1000000

owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>

=== Eligibility examples ===

==== Example eligibility 1 ====
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|Example for eligibility cost centers|600x600px|left]]

Guide: Project and Quota

2026-02-02T10:59:06Z

As1844:

== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Default case. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty eligibility|empty eligibility.]]
|-
|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
!quota flavor
!'''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" |*
|*
|
|}