Example Setup

this example setup shows one of the many possible ways to enable consent based access decisions with identos consent management tools in our example, we'll build off the get started docid\ ebqahpxicb6vwigmucrga by using an identos wallet docid\ m6 ez5lovsuqpwnwhtwnj to add a user to the authorization flow this simple consent flow\ expand todo create overview diagram by the end of this tutorial, you'll have used the wallet to do the following enroll an authorization server in the wallet (step 1) add resource definitions in the wallet (step 2) enroll a data source in the wallet (step 3) prerequisites if you'd like to try this setup for yourself, please note the following assumptions you've already completed the get started docid\ ebqahpxicb6vwigmucrga you have admin access to an identos wallet that's already installed and running (this should already be setup for you) you know how to make api calls using curl (client url command line utility) define placeholder variables step by step procedure tbd todo create overview diagram 1 enroll an authorization server enroll the authorization server used in the access management quickstart 2\ add resource definitions create the same resource types/definitions/scopes created in the authorization server from the access management quickstart 3\ enroll a data source enroll a data source (in this case, the resource server from access management quickstart; mention that an idp can also be a data source) 4\ enroll a client prerequisites configure client as uma client, add/emphasize client redirect url enroll the client from the access management quickstart example (blood glucose app) 5\ create a ticket 🌟 key concept a ticket docid\ olhbvoqp8uton5egz5war is what allows a client to obtain an access token docid\ j0pcqhmmkqigzbckmniu9 from the authorization server tickets contain all the information that defines what resources a client can access to create a ticket in the authorization server, we'll need to define the ticket purpose in the authorization server create a capability ticket in the authorization server this links the ticket purpose to the client making the request define the requested resource in the authorization server this links the client to the types of resources and scopes they can access create a requested resource capability ticket in the authorization server this combines the capability ticket and requested resource into a single ticket that represents the client's overall permissions for accessing a resource for our example, we want to create a ticket that allows the hospital's web application to read blood glucose level resources define the ticket purpose in the authorization server run the api call below to declare that the purpose of the ticket is "blood glucose app wants to read your blood glucose records " in certain authorization flows, this is the message that would be presented to an end user since this is the first purpose we're declaring, it will be id = 1 in the purpose database curl location g request patch '{{as admin uri}}' \\ \ header 'content type application/vnd api+json; ext=jsonpatch' \\ \ header 'authorization {{as admin static token}}' \\ \ header 'apiversion v1 0' \\ \ header 'accept language en' \\ \ data raw '\[ { "op" "add", "path" "/purpose", "value" { "type" "purpose", "id" 1, "attributes" { "name" "blood glucose app wants to read your blood glucose records " } } } ]' create a capability ticket for the client in the authorization server run the api call below to create the blood glucose app ticket with the unique id of blood glucose app in the capability ticket database this will also associate the capability ticket with the ticket purpose and the oauth client ( id = 1 ) created in step 3 curl location g request patch '{{as admin uri}}' \\ \ header 'content type application/vnd api+json; ext=jsonpatch' \\ \ header 'authorization {{as admin static token}}' \\ \ header 'apiversion v1 0' \\ \ header 'accept language en' \\ \ data raw '\[ { "op" "add", "path" "/capability ticket", "value" { "type" "capability ticket", "id" 1, "attributes" { "ticketid" "blood glucose app", "ticketname" "blood glucose app ticket" }, "relationships" { "purpose" { "data" { "id" 1, "type" "purpose" } }, "umaclient" { "data" { "id" 1, "type" "uma client" } } } } } ]' define the requested resource in the authorization server run the api call below to declare the blood glucose level resource definition from step 2 with the client, ticket purpose, and read scope since this is our first requested resource, it will be id = 1 in the requested resource database curl location g request patch '{{as admin uri}}' \\ \ header 'content type application/vnd api+json; ext=jsonpatch' \\ \ header 'authorization {{as admin static token}}' \\ \ header 'apiversion v1 0' \\ \ header 'accept language en' \\ \ data raw '\[ { "op" "add", "path" "/requested resource", "value" { "type" "requested resource", "id" 1, "attributes" { "maxpermissionduration" 300000000, "requestedresourceid" "8ddd9d0b 6776 4bfe 9865 b2fb9559b12312" }, "relationships" { "resourcedefinition" { "data" { "id" 1, "type" "resource definition" } }, "umaclient" { "data" { "id" 1, "type" "uma client" } } } } }, { "op" "add", "path" "/requested resource scopes", "value" { "type" "requested resource scopes", "id" 1, "attributes" {}, "relationships" { "scope" { "data" { "id" 1, "type" "scope" } }, "purpose" { "data" { "id" 1, "type" "purpose" } }, "requestedresource" { "data" { "id" 1, "type" "requested resource" } } } } } ]' create a requested resource capability ticket in the authorization server finally, run the api call below to create a single ticket that combines the capability ticket and requested resource we created in the previous api calls since this is the first ticket we're making, it will be id = 1 in the requested resources capability tickets database curl location g request patch '{{as admin uri}}' \\ \ header 'content type application/vnd api+json; ext=jsonpatch' \\ \ header 'authorization {{as admin static token}}' \\ \ header 'apiversion v1 0' \\ \ header 'accept language en' \\ \ data raw '\[ { "op" "add", "path" "/requested resources capability tickets", "value" { "type" "requested resources capability tickets", "id" 1, "attributes" {}, "relationships" { "capabilityticket" { "data" { "type" "capability ticket", "id" 1 } }, "requestedresource" { "data" { "type" "requested resource", "id" 1 } } } } } ]' ✅ step 4 complete! now that we have a ticket, the client can use the ticket to obtain an access token from the authorization server note that the client won't necessarily "have" or "present" this ticket themselves in reality, it's more of an internal record that the authorization server checks when a client requests an access token 6\ get an access token 🌟 key concept an access token docid\ j0pcqhmmkqigzbckmniu9 is a credential granted by the authorization server that allows client applications to access protected resources from a resource server the authorization server will only grant an access token if the client has a valid ticket docid\ olhbvoqp8uton5egz5war to get an access token from the authorization server, we'll need to use a ticket to request an authorization code from the authorization server use the authorization code to request an access token from the authorization server retrieve the access token from the authorization server we've already created a ticket for our client in the previous step when the client requests a protected resource, the authorization server will check the request against the client's ticket if the request is inline with the resource defintion and scopes that the client is authorized to access, then then authorization server will grant an access token to the client for our example, retrieve an authorization code from the authorization server navigate to the url below to get an authorization code expand https //{authorizationserver base url}/oauth2/authorize?\&client id=client id\&state=1648810292\&redirect uri={client redirect url}\&response type=code\&scope=read ticket the authorization code will be appended to the redirect url ( code ) in this case, the authorization code is df4ba24c ebfb 43b8 90d9 64d90f7dd647 https //{client redirect url}?code=df4ba24c ebfb 43b8 90d9 64d90f7dd647\&state=1654029277 use the authorization code to request an access token from the authorization server run the api call below to request an access token using the authorization code obtained in the previous step curl location request post 'https //{authorizationserver base url}/oauth2/token' \\ \ header 'content type application/x www form urlencoded' \\ \ data urlencode 'grant type=authorization code' \\ \ data urlencode 'redirect uri={client redirect url}' \\ \ data urlencode 'code=df4ba24c ebfb 43b8 90d9 64d90f7dd647' \\ \ data urlencode 'client assertion type=urn\ ietf\ params\ oauth\ client assertion type\ jwt bearer' \\ \ data urlencode 'client assertion=eyjrawqioijyc2exiiwidhlwijoislduiiwiywxnijoiulmyntyifq eyjzdwiioijjbgllbnrfawqilcjhdwqioij1cmx0agluz3milcjpc3mioijjbgllbnrfawqilcjlehaioje2ntqzmje4mtmsimlhdci6mty1ndmwmdixmywianrpijoimdmyztcynditowfhyi00zdkxlwi2njytzdcymjgwmtu0mjkxin0 ht8p5fetze0 2y issmxtuatf246welxjvbfx4zb3cfrppmdw2trg6bggfq8lbdtkoypzmlfieuxkntfzdpqyv6ugrtavcqercysevlhhiaxa5mb7tfuqtbfziidvdopfvaeommowc6f7whh1iuomdtp6szfm uyehzzlneerm bxr0r6un ig l6bgvnstvswtvrx7atlvob0b62fh1kp4mlc7w8joqmkowfv uvxkofftioqj6d9omwehljwpy9br ytuvfkgzxtk1s3ieax0tqt4ke0ed9kptvilkad04d7lrru2gppaq4y8s1uevshddqmdzet7wlgmgdkk5pw' retrieve the access token from the authorization server response the response will include the access token , as well as other details such as when the access token expires and what the available scopes are { "access token" "eyj0exaioijkv1qilcjhbgcioijiuzi1nij9 eyjhdwqioijodhrwolwvxc9sb2nhbghvc3q6oda4niisinn1yii6ikj1y1izagnnndnrwuhobjyxn2psuetuzw1is0j4afg1dnpxzmx5mg9psknfvkizwel1nmnycvrreufpr3rwmwiilcjyzxnvdxjjzv9vd25lcii6ijbhndhmnta5lwy0mjgtndzjni04zwi5ltrkotywowmwmtzmyiisimlzcyi6imh0dha6xc9cl2xvy2fsag9zddo4mdg0iiwicmvzb3vyy2vfawqioijvcgvuawqilcjncmfudgvkx3njb3blcyi6wyjyzwfkil0sinr5cguioijwzxjtaxnzaw9uiiwizxhwijoxnju4mjmwnzmzlcjjbgllbnrfawqioijvyxv0af91bwffy2xpzw50in0 fhwgotfg0k06l1vhnasc pkz8olcub7clubjwdssihs", "expires in" 3599, "token type" "bearer", "refresh token" "e0dd0169 36a9 4cf4 b30a 3b78c6162bc3", "scope" "read" } ✅ step 4 complete! read on to finish the setup and learn the next steps 🎉 tutorial complete! congratulations! you've just next steps tbd learn how to manage consent with the wallet? add an identity provider (as data source)