Entitlements issueshttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues2024-03-26T11:38:19Zhttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/166Add incoming request validation in Add Member API2024-03-26T11:38:19ZDeepa KumariAdd incoming request validation in Add Member APICurrently there are no validations on the email coming inside the request body for Azure.
Recently, we've enabled OID Validation: https://community.opengroup.org/osdu/platform/deployment-and-operations/helm-charts-azure/-/merge_request...Currently there are no validations on the email coming inside the request body for Azure.
Recently, we've enabled OID Validation: https://community.opengroup.org/osdu/platform/deployment-and-operations/helm-charts-azure/-/merge_requests/783
This will be a **breaking change** for AAD users: only OIDs will be accepted inside the Add member API.
Proposed Solution:
1. Add a validation inside azure layer to do the OID Validation: If the token is issued by AAD, then the incoming value inside email parameter should be a valid OID.
2. Graph API is going to be used to query the user information.M23 - Release 0.26Deepa KumariDeepa Kumarihttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/127GET /api/entitlements/v2/members/{member_email}/groups2024-01-08T07:57:35ZShane HutchinsGET /api/entitlements/v2/members/{member_email}/groupsReceived a response with 5xx status code: 500
{"code": 500, "reason:": "Internal Server Error" "message":"An unknown error has occurred" }
I expected a 4xx error
Run this curl command to reproduce this failure:
curl -X GET -H 'Aut...Received a response with 5xx status code: 500
{"code": 500, "reason:": "Internal Server Error" "message":"An unknown error has occurred" }
I expected a 4xx error
Run this curl command to reproduce this failure:
curl -X GET -H 'Authorization: Bearer TOKEN' -H 'data-partition-id: osdu' 'https://osdu.r3m18.preshiptesting.osdu.aws/api/entitlements/v2/members/%3B/groups?type='
Only tested this on AWS and AzureM22 - Release 0.25Chad LeongShane HutchinsChad Leonghttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/128DELETE and PATCH /api/entitlements/v2/groups/{group_email}2024-01-08T07:57:20ZShane HutchinsDELETE and PATCH /api/entitlements/v2/groups/{group_email}Received a response with 5xx status code: 500
{"code": 500, "reason:": "Internal Server Error" "message":"An unknown error has occurred" }
I expected a 4xx error.
Run this delete curl command to reproduce this failure:
curl -X DEL...Received a response with 5xx status code: 500
{"code": 500, "reason:": "Internal Server Error" "message":"An unknown error has occurred" }
I expected a 4xx error.
Run this delete curl command to reproduce this failure:
curl -X DELETE -H 'Authorization: Bearer TOKEN' -H 'data-partition-id: osdu' https://osdu.r3m18.preshiptesting.osdu.aws/api/entitlements/v2/groups/%25
Run this patch curl command to reproduce this failure:
curl -X PATCH -H 'Authorization: Bearer TOKEN' -H 'data-partition-id: osdu' -d '[]' https://osdu.r3m18.preshiptesting.osdu.aws/api/entitlements/v2/groups/%3B
I only tested this in AWS and Azure.M22 - Release 0.25Chad LeongShane HutchinsChad Leonghttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/129GET /api/entitlements/v2/groups/{group_email}/members2024-01-08T07:57:08ZShane HutchinsGET /api/entitlements/v2/groups/{group_email}/membersReceived a response with 5xx status code: 500
{"code": 500, "reason:": "Internal Server Error" "message":"An unknown error has occurred" }
Run this curl command to reproduce this failure:
curl -X GET -H 'Authorization: Bearer TOKEN...Received a response with 5xx status code: 500
{"code": 500, "reason:": "Internal Server Error" "message":"An unknown error has occurred" }
Run this curl command to reproduce this failure:
curl -X GET -H 'Authorization: Bearer TOKEN' -H -H 'data-partition-id: osdu' https://osdu.r3m18.preshiptesting.osdu.aws/api/entitlements/v2/groups/%3B/members
I only tested this on AWS and Azure.M22 - Release 0.25Chad LeongShane HutchinsChad Leonghttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/98Token pushed in master branch2024-01-03T12:39:27ZAnkur RawatToken pushed in master branchTokens present in the project are causing failure in Azure demo/validation environment.
Link to one such occurrence-
https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/blob/master/provider/entitlements-v...Tokens present in the project are causing failure in Azure demo/validation environment.
Link to one such occurrence-
https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/blob/master/provider/entitlements-v2-jdbc/src/test/java/org/opengroup/osdu/entitlements/v2/jdbc/interceptor/AuthTestConfig.javaChad LeongChad Leonghttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/138ADR: Return OSDU groups if API auth fails2023-12-01T23:09:15ZShikha GargADR: Return OSDU groups if API auth fails**Objective**: Understand which OSDU group a user needs to be part of to get access to a given service or data record.
**Current State**: If an API auth fails, it returns a auth fail error code but does not give any information to the u...**Objective**: Understand which OSDU group a user needs to be part of to get access to a given service or data record.
**Current State**: If an API auth fails, it returns a auth fail error code but does not give any information to the user of what steps to take to get the access.
**Desired State:** When the API auth fails, it should return the list of OSDU groups needed to access that data or service.
---
**Status:**
\[x\] Proposed
\[ \] Trialing
\[ \] Under review
\[ \] Approved
\[ \] RetiredM23 - Release 0.26Om Prakash GuptaOm Prakash Guptahttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/90Missing endpoint for getting all groups in entitlements v22023-11-24T13:51:51ZArtem Dobrynin (EPAM)Missing endpoint for getting all groups in entitlements v2# **Context:**
There is no options to get all created groups in the partition in v2 version of Entitlements. Current functionality could be used for admin (especially, DevOps) purposes.
# **How it's done today:**
We can only get all gro...# **Context:**
There is no options to get all created groups in the partition in v2 version of Entitlements. Current functionality could be used for admin (especially, DevOps) purposes.
# **How it's done today:**
We can only get all groups for current user.
# **Issue with current design:**
We do not have the endpoint providing the functionality of getting all the groups created in partition.
# **Proposal:**
Provide an API that will return all the groups created in specific partition (admin/ops access)Kateryna Kurach (EPAM)Kateryna Kurach (EPAM)https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/137ADR - test2023-11-14T21:50:57ZBanan IbrahimADR - testhttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/123ADR: remove entitlements implicit quota of how many data groups can be create...2023-09-06T13:15:34ZMingyang ZhuADR: remove entitlements implicit quota of how many data groups can be created within a data partition## Status
- [X] Proposed
- [X] Trialing
- [X] Under review
- [X] Approved
- [ ] Retired
## Context
Entitlements service implements quota for the membership that one entity can have. The quota regulates the consumption behavior and prote...## Status
- [X] Proposed
- [X] Trialing
- [X] Under review
- [X] Approved
- [ ] Retired
## Context
Entitlements service implements quota for the membership that one entity can have. The quota regulates the consumption behavior and protect the service. An entity could be a user, a service account or a entitlements group.
There is a bootstrap group called "users.data.root", and there is specific implementation to automatically add this group as children to all created data groups. The requirement behind this implementation is that any user or service account belong to the group "users.data.root" should have access to all data groups within the data partition. It also means that the user or service account have full permission to access all data within the data partition, since storage is using entitlements data groups as the record ACL. We will use the term "full data permission" below to refer to this requirement.
Quota itself is a good thing to have, however, because of the membership design of "users.data.root" group, it introduces an implicit quota which limits how many data group in total that could be created in one data partition.
Red is the current Authz; green is proposed:
![Entitlements_ADR__123.drawio](/uploads/627ac1ea959b5537d3d6d62319568751/Entitlements_ADR__123.drawio.png)
## Tradeoff Analysis
The advantage of adding "users.data.root" group to all data groups is that it hides the "full data permission" requirement implementation details from other services. Therefore, only the entitlements code needs to be changed originally to support this requirement and all other services who requires data authorization will automatically get this feature.
However, on the other hand, it introduces an implicit quota which limits how many data groups can created within the data partition. Such implicit quota constrains the group scalability and usability from the application. E.g. Let's assume the membership quota to be 5000, due to the implicit quota, it limits only 5000 data groups can be created within the data partition. When this quota met, applications can't create any new group, so it blocks the application functionalities. And when this quota met, the average membership of individual user or service account may still be a small number, so it does not fully utilize the service.
> **ⓘ** Additional tradeoffs include that requiring each service to check for a group itself rather than relying on the entitlements service breaks
>
>- the [non-functional agility requirement](https://gitlab.opengroup.org/osdu/r3-program-activities/docs/-/raw/master/R3%20Document%20Snapshot/07-osdu-reference-architecture.pdf) since any change to this dependency requires touching all services
>- transparency, since the entitlements service is no longer authoritative
>- the [single-responsibility principle](https://en.wikipedia.org/wiki/Single-responsibility_principle), since a service is now responsible for authorization in addition to its main function.
## Decision
It is not a good idea to support "full data permission" by group hierarchy and ACL based entitlement. Such requirement should be implemented with role based or policy based entitlement. We'd like to propose a new design for this:
1. Entitlements service drops the implementation of adding "users.data.root" to all data groups. Therefore, it removes the undesired implicit quota of how many data groups can be created within a data partition.
2. Any downstream service which does data authorization with ACL checking should implement a new logic of checking whether the caller belongs to "users.data.root", if so, service should bypass the ACL checking and give the full data permission. Since all the services are using entitlements service to do API authorization, it already has the API request, no extra performance overhead will be added to the downstream services. Eventually, this logic should be converted to instance policy when the downstream services integrate with the policy service.
## Consequences
All downstream services which do data authorization by ACL checking needs to be reviewed whether they need the code change to support "full data permission" requirement.
> **ⓘ** This ADR grows the technical debt (growing the data authz logic in the search and storage service).
>
>The Policy service could address many of tradeoffs described above as well as the technical debt by abstracting these checks out of the services; however
>
>- The Policy service is non-performant for as few as 50 groups, so many will use the hard-coded approach initially.
>- It is difficult to unwind implementation of a temporary solution. For instance, our understanding is that the Storage service bypasses the Policy service entirely and calls OPA directly (also for performance reasons).
>
>For these reasons, Google Cloud suggests careful and persistent documentation of the technical debt which will need to be unwound in future.
As an agreement to balance between business feature development and technical debt, this ADR will add data manager authorization logic to both downstream services and OPA as a new policy. The reason we still need to add this hard coded logic to all downstream services is because policy is not 100% released yet, and the hard coded data authorization logic is still used in production. Since it will implement the new data manager policy in OPA, this ADR won't add any technical debt or logic discrepancy to policy service. The above technical debt can only be resolved when policy service releases to production and within its own tasks, it should remove all the hard coded data authz logic from all downstream services.
### Identified impact services
Entitlements (MR: https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/merge_requests/477)
Storage (MR: https://community.opengroup.org/osdu/platform/system/storage/-/merge_requests/694)
Search (has been already implemented the logic in the MR: https://community.opengroup.org/osdu/platform/system/search-service/-/merge_requests/298)
Seismic DMS
*To Be Added*M19 - Release 0.22Mingyang ZhuMingyang Zhuhttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/125Entitlements service is restarting preventing us to complete deployment on Azure2023-08-07T09:56:55ZPaweł GrudzieńEntitlements service is restarting preventing us to complete deployment on AzureAfter going through manual installation in infra-azure-provisioning the entitlements service is getting restarted.
Link to manual deployment:
https://community.opengroup.org/osdu/platform/deployment-and-operations/infra-azure-provisioni...After going through manual installation in infra-azure-provisioning the entitlements service is getting restarted.
Link to manual deployment:
https://community.opengroup.org/osdu/platform/deployment-and-operations/infra-azure-provisioning
We conducted the deployment using version 0.19 and master. Both got us stuck on entitlements not working. Attached logs.
[entitlements-689f678cb6-xs2tb__1_.log](/uploads/c210c21402739828596c2df49565ed48/entitlements-689f678cb6-xs2tb__1_.log)
Maybe we are missing something but it looks that the ground up instructions need some work in order to put the infrastructure in working condition.
Analysis of the logs points to non specific errors that we are unable to resolve and I don't know if they are causing the restart:
1. logs
2.
```
2023-05-18 08:07:42,849 main ERROR Appenders contains an invalid element or attribute "AzureIfxAuditAppender"
2023-05-18 08:07:43,352 main ERROR Unable to locate appender "azureAuditAppender" for logger config "AzureAuditLogger"
2023-05-18 08:07:46,634 main ERROR Appenders contains an invalid element or attribute "AzureIfxAuditAppender"
2023-05-18 08:07:46,639 main ERROR Unable to locate appender "azureAuditAppender" for logger config "AzureAuditLogger"
```
2. logon problem
```
2023-05-18 08:08:19.361 INFO entitlements-689f678cb6-xs2tb --- [ main] c.a.i.EnvironmentCredential correlation-id= data-partition-id= api-method= operation-name= user-id= app-id=:Azure Identity => EnvironmentCredential invoking ClientSecretCredential
2023-05-18 08:08:19.534 INFO entitlements-689f678cb6-xs2tb --- [ main] c.a.c.i.j.JacksonVersion correlation-id= data-partition-id= api-method= operation-name= user-id= app-id=:Package versions: jackson-core=2.14.0, jackson-databind=2.14.0, jackson-dataformat-xml=2.14.1, jackson-datatype-jsr310=2.14.1, azure-core=1.35.0, Troubleshooting version conflicts: https://aka.ms/azsdk/java/dependency/troubleshoot
**2023-05-18 08:08:21.165 ERROR entitlements-689f678cb6-xs2tb --- [ main] c.a.i.i.IntelliJCacheAccessor correlation-id= data-partition-id= api-method= operation-name= user-id= app-id=:IntelliJ Authentication not available. Please log in with Azure Tools for IntelliJ plugin in the IDE.**
2023-05-18 08:08:31.404 INFO entitlements-689f678cb6-xs2tb --- [onPool-worker-1] c.a.i.ClientSecretCredential correlation-id= data-partition-id= api-method= operation-name= user-id= app-id=:Azure Identity => getToken() result for scopes [https://vault.azure.net/.default]: SUCCESS
2023-05-18 08:08:31.443 INFO entitlements-689f678cb6-xs2tb --- [onPool-worker-1] c.a.i.DefaultAzureCredential correlation-id= data-partition-id= api-method= operation-name= user-id= app-id=:Azure Identity => Attempted credential EnvironmentCredential returns a token
2
```
This is the main suspect although the following lines suggest that the service is starting completely fine getting all the variables logging on fine.
Please help getting to the root of the problem.https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/130LOCAL_MODE: x-user-id is not forwarded to partitions servcie2023-07-27T08:22:03ZGhassen BouzidLOCAL_MODE: x-user-id is not forwarded to partitions servcieI'm sending the following HTTP request to the Entitlement service
`curl -X GET -H 'Authorization: Bearer TOKEN' -H 'slb-data-partition-id: osdu' -H 'x-user-id: user-id -H 'data-partition-id: partition-id' -H 'account-id: account-id' 'ht...I'm sending the following HTTP request to the Entitlement service
`curl -X GET -H 'Authorization: Bearer TOKEN' -H 'slb-data-partition-id: osdu' -H 'x-user-id: user-id -H 'data-partition-id: partition-id' -H 'account-id: account-id' 'https://osdu.r3m18.preshiptesting.osdu.aws/api/entitlements/v2/groups'`
The request is not authorized by Partiton service since it doesn't contain the x-user-id header.
Am I doing sthg wrong?https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/110ADR: [Entitlements] Upgrade bootstrapping of initial accounts (enable multi SA)2023-07-05T08:14:48ZRiabokon Stanislav(EPAM)[GCP]ADR: [Entitlements] Upgrade bootstrapping of initial accounts (enable multi SA)## Status
- [X] Proposed
- [X] Trialing
- [X] Under review
- [X] Approved
- [ ] Retired
**Context**
Entitlements /InitApi REST API is used for bootstrapping of each new tenant's roles and system principals accounts.
Currently InitApi ...## Status
- [X] Proposed
- [X] Trialing
- [X] Under review
- [X] Approved
- [ ] Retired
**Context**
Entitlements /InitApi REST API is used for bootstrapping of each new tenant's roles and system principals accounts.
Currently InitApi uses the only single available implementation of `TenantInitService` interface implemented in the `DefaultTenantInitServiceImpl` class. It invokes `bootstrapInitialAccounts()` method that bootstraps user accounts and grants them roles in accordance with JSON configuration files placed in CSPs' `resources/provisioning/accounts/` folders.
The current algorithm is restricted by the hardcoded functionality of the `private Map<String, String> createUserEmails()` method, which populates the list of accounts to be bootstrapped by only one item with `SERVICE_PRINCIPAL` key and `requestInfo.getTenantInfo().getServiceAccount()`.
**Reason**
It's unlikely that all CSPs and consumers are going to use one single account per tenant for all purposes, if not now then in the future responsibilities will be divided between different entities. This set of responsibilities will likely become part of platform installation\bootstrapping. To reduce bootstrap and installation complexity we need to improve bootstrapping API accordingly.
**Decision**
_Aliases for all accounts that could be bootstrapped_
InitApi POST body to transmit alias-to-account mappings. Currently, the method is not expecting and reading any info from the body.
We could extend it and read mappings from the body, expected to be a JSON document of the following structure and content:
~~~
{
"aliasToSAMappings": [
{
"alias": "WHATEVER_ACCOUNT_CSP_NEEDS_TO_BOOTSTRAP",
"id": "my.account@email.com"
},
{
"alias": "ANY_OTHER_ACCOUNT",
"id": "other.account.@email.com"
}
]
}
~~~
To pass the body content through components (from the controller to the finite service) the following common code components’ methods’ signatures should be changed:
InitApi (RestController) initiateTenant() method – add @RequestBody Object body parameter
TenantInitService interface bootstrapInitialAccounts() method – add Object body parameter
DefaultTenantInitServiceImpl class bootstrapInitialAccounts() method – add Object body parameter
_Role definition JSON files for all account aliases_
**How to handle** such aliases could be defined by each CSP as they want, for GCP we will use
Compose a set of JSON configuration files, one for each account alias.
And add them to existing provisioning resources `provisioning/*** files.M14 - Release 0.17Riabokon Stanislav(EPAM)[GCP]Andrei Dalhikh [EPAM/GC]Riabokon Stanislav(EPAM)[GCP]https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/61Add support for Entitlement membership change event in OSDU2023-06-19T10:01:23ZNitin-slbAdd support for Entitlement membership change event in OSDUConsuming applications needs to be notified of any entitlement membership changed.Consuming applications needs to be notified of any entitlement membership changed.https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/50Get cache expiration info from partition service2023-01-18T19:22:19ZRostislav Vatolinvatolinrp@gmail.comGet cache expiration info from partition serviceCached groups should have configurable ttl (cache time to live) property. This property should be different depending on data partition id. This property should be kept in PartitionInfo and retrieved using partition service. Property in ...Cached groups should have configurable ttl (cache time to live) property. This property should be different depending on data partition id. This property should be kept in PartitionInfo and retrieved using partition service. Property in PartitionInfo table has an integer value, which represents ttl in milliseconds.https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/116In Azure Platform Validation environment while creating new data group using...2022-10-20T14:22:43ZKamlesh TodaiIn Azure Platform Validation environment while creating new data group using Entitlements API, one is getting 412 - Precondition Failed message.In platform Validation envrionment (osdu-demo.msft-osdu-test.org)
Request
POST https://osdu-demo.msft-osdu-test.org/api/entitlements/v2/groups
{
"name": "data.certification81127.viewers",
"description": "Certification Test Data group...In platform Validation envrionment (osdu-demo.msft-osdu-test.org)
Request
POST https://osdu-demo.msft-osdu-test.org/api/entitlements/v2/groups
{
"name": "data.certification81127.viewers",
"description": "Certification Test Data group with Viewer access"
}
Response
{
"code": 412,
"reason": "Precondition Failed",
"message": "preshipping@azureglobal1.onmicrosoft.com's group quota hit. Identity can't belong to more than 5000 groups"
}Yaraslau SushchykNaveen RamachandraiahSrinivasan NarayananYaraslau Sushchykhttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/102Broken link for Entitlement service in Security and Compliance Wiki2022-05-27T11:17:33ZAha!Broken link for Entitlement service in Security and Compliance WikiThe entitlement service link is broken in [https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/wikis/home](https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/wikis/home)
**The correct l...The entitlement service link is broken in [https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/wikis/home](https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/wikis/home)
**The correct link is below:**
[https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements](https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements)
Several other places that referred to this link above is also broken, mainly found in:
[https://community.opengroup.org/osdu/platform/system/storage/-/blob/master/docs/tutorial/StorageService.md](https://community.opengroup.org/osdu/platform/system/storage/-/blob/master/docs/tutorial/StorageService.md)
Created from Aha! https://osdu.aha.io/features/SEC-1
I'm changing this description in GitLabM11 - Release 0.14https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/94Please make checking before creating a group or creating a user atomic2022-05-25T13:43:57ZRostislav Vatolinvatolinrp@gmail.comPlease make checking before creating a group or creating a user atomicPlease make checking before creating a group or creating a user atomic in Azure implementation.
At this moment, checking if a group exists is done via separate call to database. Please use single call to verify if group or user exists to...Please make checking before creating a group or creating a user atomic in Azure implementation.
At this moment, checking if a group exists is done via separate call to database. Please use single call to verify if group or user exists together with create operation.Rostislav Vatolinvatolinrp@gmail.comRostislav Vatolinvatolinrp@gmail.comhttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/105[BUG] Delete member API permission issue2022-05-09T17:15:50ZRostislav Vatolinvatolinrp@gmail.com[BUG] Delete member API permission issueEntitlements service has an API: DELETE /members/{member_email}<br/>
This API is used to remove member from every group where he is a member or an owner within a data partition.<br/>
To access this API the requestor should have OPS role....Entitlements service has an API: DELETE /members/{member_email}<br/>
This API is used to remove member from every group where he is a member or an owner within a data partition.<br/>
To access this API the requestor should have OPS role.
**Issue to address**: internally requestor is also checked to be an owner of the group, from which he removes a user. This should not be done, because requestor has ops role.
**How to reproduce the issue:**<br/>
Given: user A, user B, user C. User C has OPS role.<br/>
User A creates a group.<br/>
User A adds user B as a member in the new group.<br/>
Group is created, User A is an OWNER and User B is a MEMBER.<br/>
User C calls API DELETE /members/{member_email} to delete user from all groups.<br/>
Actual result: 401 returned "Not authorized to manage members"<br/>
Expected result: 204<br/>https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/30Azure specific variable in core code2022-04-12T20:34:42ZRucha DeshpandeAzure specific variable in core codeA Bean in core code requires azure.keyvault.url variable to be set. Without it, the application fails to start.
https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/blob/master/entitlements-v2-core/src/ma...A Bean in core code requires azure.keyvault.url variable to be set. Without it, the application fails to start.
https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/blob/master/entitlements-v2-core/src/main/java/org/opengroup/osdu/entitlements/v2/di/LibraryBeanConfiguration.java
`import javax.inject.Named;
@Configuration
@ComponentScan("org.opengroup.osdu.core.common")
public class LibraryBeanConfiguration {
@Value("${azure.keyvault.url}")
private String keyVaultURL;
@Bean
public IHttpClient getHttpClient() {
return new HttpClient();
}
@Bean
@Named("KEY_VAULT_URL")
public String keyVaultURL() {
return keyVaultURL;
}
}
`ethiraj krishnamanaiduJoeRucha DeshpandeBill Wangethiraj krishnamanaiduhttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/103[BUG] Swagger page could not be displayed2022-03-24T15:14:49ZRostislav Vatolinvatolinrp@gmail.com[BUG] Swagger page could not be displayedSwagger page could not be displayed after recent upgrade of springfox-boot-starter to 3.0.0Swagger page could not be displayed after recent upgrade of springfox-boot-starter to 3.0.0M11 - Release 0.14Rostislav Vatolinvatolinrp@gmail.comRostislav Vatolinvatolinrp@gmail.com