{"id":19992635,"url":"https://github.com/HealthCatalyst/Fabric.Authorization","last_synced_at":"2025-05-04T11:31:41.071Z","repository":{"id":53439771,"uuid":"90079030","full_name":"HealthCatalyst/Fabric.Authorization","owner":"HealthCatalyst","description":"Permissions service for applications","archived":true,"fork":false,"pushed_at":"2021-03-30T14:43:32.000Z","size":5408,"stargazers_count":21,"open_issues_count":29,"forks_count":13,"subscribers_count":15,"default_branch":"master","last_synced_at":"2024-11-13T04:55:30.746Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"C#","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/HealthCatalyst.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"license.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null}},"created_at":"2017-05-02T21:20:07.000Z","updated_at":"2023-11-16T14:58:04.000Z","dependencies_parsed_at":"2022-08-17T19:15:25.875Z","dependency_job_id":null,"html_url":"https://github.com/HealthCatalyst/Fabric.Authorization","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/HealthCatalyst%2FFabric.Authorization","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/HealthCatalyst%2FFabric.Authorization/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/HealthCatalyst%2FFabric.Authorization/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/HealthCatalyst%2FFabric.Authorization/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/HealthCatalyst","download_url":"https://codeload.github.com/HealthCatalyst/Fabric.Authorization/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252329568,"owners_count":21730637,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-13T04:52:15.196Z","updated_at":"2025-05-04T11:31:36.063Z","avatar_url":"https://github.com/HealthCatalyst.png","language":"C#","funding_links":[],"categories":["C\\#"],"sub_categories":[],"readme":"[![Build status](https://healthcatalyst.visualstudio.com/_apis/public/build/definitions/eaeb1198-1e3e-4938-88f1-918e8bf769af/315/badge)](https://healthcatalyst.visualstudio.com/_apis/public/build/definitions/eaeb1198-1e3e-4938-88f1-918e8bf769af/315/badge)\n[![Codacy Badge](https://api.codacy.com/project/badge/Grade/b3fb1a95c9f249f3a1151be442fc23cb)](https://www.codacy.com/app/HealthCatalyst/Fabric.Authorization?utm_source=github.com\u0026amp;utm_medium=referral\u0026amp;utm_content=HealthCatalyst/Fabric.Authorization\u0026amp;utm_campaign=Badge_Grade)\n# Overview\n\nThe purpose of the authorization API is to allow client applications (aka relying party applications) to easily store and retrieve application level permissions. Client applications will submit all requests using the access token provided by the Identity Service. That access token will contain the sub (openid user identification) and groups claims along with the id of the client application. If the Access token is not present the Authorization service will respond with a 403 forbidden response. Below are details of the Authorization Service API:\n\n# Resources\n[User](https://github.com/HealthCatalyst/Fabric.Authorization/wiki/User)  \n[Groups](https://github.com/HealthCatalyst/Fabric.Authorization/wiki/Groups)  \n[Roles](https://github.com/HealthCatalyst/Fabric.Authorization/wiki/Roles)  \n[Permissions](https://github.com/HealthCatalyst/Fabric.Authorization/wiki/Permissions)  \n\n# Key Design Considerations\nBelow are some key design considerations we are thinking through as we build out the service.\n\n## Leverage Third Party Identity Provider Groups\nWe intend to leverage third party identity providers to provide the groups that a user is in.\nThis will allow relying party applications to map roles to groups maintained by the client's IT staff.\nThis way a client can manage their own groups and relying parties do not have to be involved with managing individual users directly.\n\n## Hierarchical Permission Model\nSome relying party applications that we will support have more complex needs. \nTo that end we have come up with a hierarchical model for permissions.\n\nA permission will consist of three parts:\n\n`{grain}/{resource}.{permission}`\n\nWe will have three top level reserved grains:\n```\npatient \nuser\napp\n```\n\nA relying party application will store its permissions under the `app` grain.\nFor example, lets say we had an app with a clientid `myclientapp1`. \nThe permissions for that application would look like:\n\n```\napp/myclientapp1.manageusers\napp/myclientapp1.createalerts\napp/myclientapp1.createdocument\n```\n\nNow lets say that relying party application needed to secure additional resources within the application,\nfor example a document that a user was able to create based on the `app\\myclientapp1.createdocument`\npermission. Those permissions might look like:\n\n```\nmyclientapp1/mynewdocument.edit\nmyclientapp1/mynewdocument.delete\n```\n\nThey can be created in the Authorization service via the API, and associated to the appropriate role.\n\nThe `patient` and `user` grains will be used to manage permissions to FHIR \nbased data services and are based on FHIR scopes and resource which you can read \nmore about [here](http://docs.smarthealthit.org/authorization/scopes-and-launch-context/).\n\nThe `app` grain is where all custom application permissions will live.\n\nThis is how we will conceptually separate data permissions from app permissions.\n\n## Prefer Fast Reads\nWe expect that the bulk of the traffic to the Authorization service to be for reading permissions related to a user via their groups.\nAs a result, we shaped the /User/Permissions api to return a condensed format for permissions using the above string based model istead of returning a verbos json representation for each permission.\nIn additiona by default, we plan to only return the top level permissions for an application based on the clientid. So a request to:\n`GET /user/permissions` from the relying party application with a client id of `myclientapp1` would return only permissions in the `app/myclientapp1` grain/resource combination.\nThe relying party application can make a subsequent request to get the nested permissions by supplying the grain and resource query string parameters.\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FHealthCatalyst%2FFabric.Authorization","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FHealthCatalyst%2FFabric.Authorization","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FHealthCatalyst%2FFabric.Authorization/lists"}