Third-party developer building a FHIR Bulk request for DocumentReference Resource for a Payer. Practice is asking what security measures are going to be applied to ensure you only request documents for their Members.
Is there a way to limit the view to only Payer 1 Members when requesting the documents?
Is there a way to limit our access to only their Members in the Practice EHR.
It appears the only security parameters are audit trails and legal documents you sign to state what you plan on viewing but nothing at a programming or rights level for System Access FHIR calls.
I have researched all known documentation and web searches to view setting scopes and they were only focused on Patient and Provider FHIR access not System FHIR access.
Related
We are using the CalendarView endpoint to retrieve a users appointments for a specific time period. While calling the endpoint we are passing $select=start,end,showAs to only retrieve the fields that we are interested in.
Our end client is concerned that even though we are filtering the results on our side we still have access to Calendars.Read and technically have access to read meeting subjects, etc. Is there any way in Office365 or the Graph API that our end client can apply more granular permissions to filter which fields we have access to?
Today Microsoft Graph application permissions give your application full access to the entity they cover (all the properties)/the endpoint (all the payload).
There's is no way to restrict access to specific properties of an entity for a specific application.
You can always suggest this idea on uservoice.
I have some doubts regarding the custom connector we are trying to build for docusign : -
Regarding the license plan that need to be bought by the customers who will be granting access for our connector to collect data from their docusign organization account. I am looking at the link https://www.docusign.com/products-and-pricing. API access support is mentioned in only the advanced solution. So I was wondering whether only we need to have "Advanced solutions plan with APIs support" plan or all our customers need to API access support in order to fetch their data.
As per the documentation, to make the REST API calls we need two fields 'base_uri' and 'account_id' (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints). Now, the response of userInfo API call gives an array of accounts and its respective fields. My doubt is, if multiple authenticated users (more than one accounts) are returned in this array but all are part of same organization, will they all have different account_ids. Main concern here is, will there be several Base Paths (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints#form-your-base-path) to make API calls?
2a. Further question is, what is the significance of 'is_default' field?
Is this related to main account (if is_default is true) using which we will create our Base Path?
Since this is a tech/engineering forum I'm going to answer only question #2 as question #1 is more of a business/sales question.
The reason you may get multiple accounts is that an authenticated user in DocuSign can be a member of multiple accounts. That said, it's the same user. Meaning, say foobar#blah.com has an account 123 with company X and account 456 with his school, then it's possible that when foobar#blah.com authenticates (With the same password!) to DocuSign we have a list of accounts associated with that user. We give you all of them when you make the API call. The default one is the main one that you would see when you log into our web app. You can decide yourself as the user which one is the default. Users who log into our web-app then see an option at the top-right to change accounts.
and yes, every API call is associated with a specific account. So when you construct the urls for your API - you do need to know which account for this user you are making the API call for. Your application can decide how to handle this.
Hope this helps.
I am trying to use power bi embedded service rest apis with a pro account, I have gone through the rest api reference guide -
https://learn.microsoft.com/en-us/rest/api/power-bi
The issue is that am unable to share a report with a particular set of users with the api, now i know that we can with rest api create appspaces/groups, and add users to group, but thats at the group level. I want to basically give permission at the report level. It is very easily possible from the app.powerbi.com portal by going into the share option. But there is no api that i can find to share a report to a user in an appspace.
We are stuck in our POC because of this as report level security is basic and a must have requirement for any kind of custom usage.
Currently Power BI REST API doesn't allow you to do that. As you said, you can only manage users on workspace level. If you need such dynamic report level management, you can try to achieve this by removing the rights of your users on the workspace and embed the reports in some application, implementin "app own data" scenario. This way you will be able to manage user's access in your application, while the reports will be always accessed with your "master account".
In the systems, there may be data that is restricted in nature.
Sometimes access to specific entities should be easily restricted or granted based on user or group membership.
What is the best way to implement this in the microservice architecture?
#1
Should access control, managing permissions etc. be the responsibility of the microserive itself? Developers will have to implement access control, store, and update permissions for every service. Seems like not very robust and error-prone approach.
#2
Create dedicated microservice handling permission management? This service will be called by other microserives to check access permissions for each entity and filtering entities before returning results. Centralized permissions storage and management is an advantage but microservice will have to make a call to "Permission Service" for each entity to check access rights what may have a negative influence on performance. And developers still have to integrate access checks into their services what leaves space for an error.
#3
Make access control responsibility of the API Gateway or Service Mesh. It is possible to think of an implementation that will automatically filter responses of all services. But in the case when the microservice returns list of entities permissions should be checked for each entity. Still a potential performance problem.
Example
Consider the following synthetic example.
Healthcare system dealing with test results, X-Ray images etc. Health information is very sensitive and should not be disclosed.
Test results should be available only to:
patient
doctor
laboratory
Attending doctor may send the patient to another specialist. A new doctor should have access to test results too. So access can be granted dynamically.
So each entity (e.g. test results, X-Ray image) has a set of rules what users and groups are allowed to access it.
Imagine there is a microservice called "Test Results Service" dealing with test results. Should it be responsible for access control, manage permissions etc.? Or permissions management should be extracted to separate microservice?
Healthcare system may also handle visits to a doctor. Information about patient's visit to the doctor should be available to:
patient
doctor
clinic receptionist
This is the example of a different entity type that requires entity level access restriction based on user or group membership.
It is easy to imagine even more examples when entity level access control is required.
I came to the following generic solution.
ACL security model is used. Each object in the system has associated set of permissions. Permissions defines who and what actions can perform on the object.
Microservices are responsible for entity-level authorization and filter objects in responses based on permissions of the objects.
Central Access Control Service is responsible for the creation, update, and deletion of permissions for all objects in the system. Access Control Service database is the primary store of objects' permissions.
Permissions stored in microservices databases are synchronized with Access Control Service database using event-carried state transfer. Every time, permissions are changed an event is sent to the message broker. Microservices can subscribe to these events to synchronize permissions.
API Gateway can be used as the additional protection layer. API Gateway can call Access Control Service directly (RPC) to check response objects' permissions or load recently revoked permissions.
Design features:
A way to uniquely identify each object in the system is required (e.g. UUID).
Permissions synchronization in microservices are eventual consistent. In case of partitioning between message broker and microservice permissions will not be synchronized. It may be a problem with revocation of the permissions. The solution to this problem is a separate topic.
Looks like security is a part of business logic here. In both examples.
Then security could be a part of data scheme.
For example,
Patient can see his tests:
select * from test_result where patient_id=*patient_id*
Doctor can see all test from his medical department:
select * from test_result where branch_id=*doctor_branch*
I believe that to have separate MS for access control is a really bad idea and could lead serious performance problems. Just imagine situation that somebody with zero entity access tries to fetch all entities each time :) You will always need to handle larger result sets than actually needed.
Firstly, this is very bad idea to have a separate (per microservice) security model. It should be single always cross-cutting all application, because it can lead to a hell with access management, permissions granting and mapping between entities in different microservices.
In second, I assume that you are wrong with understanding how to organize microservices..? You should dedicate the principle of splitting functionality into microservices: by features, by domain, etc. Look at Single Responsibility, DDD and other approaches which helps you to achieve clear behavior of your MS.
So, in best case, you should have to:
Choose right security model ABAC or RBAC - there are a lot of other options, but looking at your example I guess the ABAC is the best one
Create separate MS for access management - the main responsibility of this MS is a CRUD and assignment of groups/roles/permissions/attributes to the people accounts.
Create separate MS for providing only permitted health information.
In third, how it works?:
With ABAC you can setup hierarchical roles/permissions (based on groups/attributes) - it helps you to resolve a delegation path of who is permitted to the data
Setup authorization (via auth-MS) and store the list of permissions (in session, cookies, etc)
Check access for a given user for a needed data in health-info-MS. Here we have several options how to do this:
If you use memory-grids (hazelcast, coherence), you can easily create filters with predicates based on security attributes.
If you're using SQL (hibernate, plain SQL, etc.) you should generate queries to return only permitted data - add security specific criteria to the where clause
Few more details about SQL queries with security check in where: before the SQL execution (if hibernate & spring is easy to do with spring-method-auth hook) you should resolve all permissions assigned to a user - you can do this with call to auth-MS.
Example
We created CRUD permissions for TestResult entity - VIEW, EDIT, DELETE.
The role DOCTOR can see any TestResults - so, it has VIEW permission
The role PATIENT can see only his/her TestResults
So, you create a business rules which provide the correct where clause for each business role (DOCTOR, PATIENT, LAB, etc.) and at the end the SQL request would be like:
For patient who has assigned VIEW permission:
select * from test_result where id=*patient_id* and 1=1
For patient who hasn't assigned VIEW permission:
select * from test_result where id=*patient_id* and 1!=1
NOTE: In business rules we can add 1=1 or 1!=1 to permit/restrict query result
I am developing an integration with REST Api with yodlee, and I am worry about security considerations, and would like to hear about the best practices concerning security with the server that talks with yodlee via REST API.
There is a method that returns the users password in plain text, getLoginFormCredentialsForItem()
This worries me a lot and I see that I have to isolate this server with the application server.
Do you have any recommendation to confront this scenario?
Thanks for your feedback on this. I've reviewed this with our Yodlee Security team and they've provided the following response:
The Yodlee Platform stores consumer credentials in a reversible format so that we can use those credentials on behalf of, and as authorized by, the consumer in order to retrieve their data for use by the application. Yodlee has enacted multiple layered security controls as defined by US banking regulations, industry standards (e.g. ISO2700K, PCI) and good industry practices to protect these credentials and the data retrieved by them. When Yodlee deploys with a client, access to the APIs are restricted via network and API level access control lists to complement our and our client’s security controls. However, in this Developer Portal, all APIs are white-listed so that developers can explore the full feature set of the Platform.
We're a longstanding platform with over 10+ years of security and bank-level data audits under our belt and we do not take these or any security concerns lightly. As part of our audit process, we will review the need and use of this particular API and make the appropriate determination whether to modify or remove this API completely from use. We thank you for bringing this concern to our attention.