![\"FIWARE](\"https://nexus.lab.fiware.org/repository/raw/public/badges/chapters/security.svg\")
This tutorial introduces an additional security generic enabler - Authzforce\nand adds fine grained control to the security rules generated by Keyrock.\nAccess to the entities created in the\nprevious tutorial is now\nconfigured and controlled using an XACML access control policy - this creates a\nflexible ruleset which can be uploaded and reinterpreted on the fly so complex\nbusiness rules can be created and changed according to current circumstances.
\nThe tutorial discusses code showing how to integrate Authzforce within a web\napplication and demonstrates examples of Authzforce XACML Server-PDP\ninteractions. cUrl commands are used to show the\ninteractions between generic enablers.
\nThe docker-compose files for this tutorial can be found on GitHub:
![\"GitHub\"](\"https://fiware.github.io/tutorials.XACML-Access-Rules/icon/GitHub-Mark-32px.png\"){kind=icon}
FIWARE 405: Ruleset Based Permissions
\n\n\"Say: Come, I will rehearse what Allah hath prohibited you from:
\n\n
\n- Join not anything as equal with Him
\n- Be good to your parents
\n- Kill not your children on a plea of want - We provide sustenance for you\nand for them
\n- Come not nigh to shameful deeds. Whether open or secret
\n- Take not life, which Allah hath made sacred, except by way of justice\nand law
\nthus doth He command you, that ye may learn wisdom.\"
\n— Quran 6.151, Sūrat al-Anʻām
\n
Previous tutorials have\nintroduced a simple access control system based on authentication (level 1) or\nbasic authorization access to resources based on a role (level 2). These\npolicies are easy to create, but the rules within them are very black and white,\nrules cannot rely on one another, have exception clauses or offer access based\non time limits or attribute values. There is also no mechanism to resolve\ndifferent rules in the case of conflict.
\nTo satisfy a complex access control scenario, an additional arbitration\nmicroservice is required, which is able to come to a judgement on each\nPermit/Deny policy decision by reading and interpreting the full set of access\ncontrol rules, and based their judgement on the evidence provided by the\nrequesting service.
\nFIWARE Authzforce is a service\nwhich is able to provide such an interpretive Policy Decision Point (PDP). It is\nan advanced access control Generic Enabler which is able to interpret rules\nsupplied using the\nXACML standard.\nRulesets can be amended and uploaded at any time providing a flexible method to\nmaintain security policies which can change according to business need.\nFurthermore the language used to describe the access policy is designed to be\nhighly extensible and cover any access control scenario.
\neXtensible Access Control Markup Language (XACML) is a vendor neutral\ndeclarative access control policy language. It was created to promote common\naccess control terminology and interoperability. The architectural naming\nconventions for elements such as Policy Execution Point (PEP) and Policy\nDecision Point (PDP) come from the XACML specifications.
\nXACML policies are split into a hierarchy of three levels - <PolicySet>,\n<Policy> and <Rule>, the <PolicySet> is a collection of <Policy>\nelements each of which contain one or more <Rule> elements.
Each <Rule> within a <Policy> is evaluated as to whether it should grant\naccess to a resource - the overall <Policy> result is defined by the overall\nresult of all <Rule> elements processed in turn. Separate <Policy> results\nare then evaluated against each other using combining alogorthms define which\n<Policy> wins in case of conflict.
A <Rule> element consists of a <Target> and a <Condition>. This is an\nexample <Rule>, it states access will be granted (Effect=\"Permit\") when a\nPOST request is sent to the /bell/ring endpoint, provided that the\nsubject:role has been provided and that the\nrole=security-role-0000-0000-000000000000 :
<Rule RuleId=\"alrmbell-ring-0000-0000-000000000000\" Effect=\"Permit\">\n <Description>Ring Alarm Bell</Description>\n <Target>\n <AnyOf>\n <AllOf>\n <Match MatchId=\"urn:oasis:names:tc:xacml:1.0:function:string-equal\">\n <AttributeValue DataType=\"http://www.w3.org/2001/XMLSchema#string\">/bell/ring</AttributeValue>\n <AttributeDesignator Category=\"urn:oasis:names:tc:xacml:3.0:attribute-category:resource\" AttributeId=\"urn:thales:xacml:2.0:resource:sub-resource-id\" DataType=\"http://www.w3.org/2001/XMLSchema#string\" MustBePresent=\"true\" />\n </Match>\n </AllOf>\n </AnyOf>\n <AnyOf>\n <AllOf>\n <Match MatchId=\"urn:oasis:names:tc:xacml:1.0:function:string-equal\">\n <AttributeValue DataType=\"http://www.w3.org/2001/XMLSchema#string\">POST</AttributeValue>\n <AttributeDesignator Category=\"urn:oasis:names:tc:xacml:3.0:attribute-category:action\" AttributeId=\"urn:oasis:names:tc:xacml:1.0:action:action-id\" DataType=\"http://www.w3.org/2001/XMLSchema#string\" MustBePresent=\"true\" />\n </Match>\n </AllOf>\n </AnyOf>\n </Target>\n <Condition>\n <Apply FunctionId=\"urn:oasis:names:tc:xacml:3.0:function:any-of\">\n <Function FunctionId=\"urn:oasis:names:tc:xacml:1.0:function:string-equal\" />\n <AttributeValue DataType=\"http://www.w3.org/2001/XMLSchema#string\">security-role-0000-0000-000000000000</AttributeValue>\n <AttributeDesignator Category=\"urn:oasis:names:tc:xacml:1.0:subject-category:access-subject\" AttributeId=\"urn:oasis:names:tc:xacml:2.0:subject:role\" DataType=\"http://www.w3.org/2001/XMLSchema#string\" MustBePresent=\"false\" />\n </Apply>\n </Condition>\n</Rule>\nThis is a very verbose method for creating a simple Verb-Resource access rule,\nbut unlike simple Verb-Resource rules, with XACML, other more complex\ncomparisons can be made, for example checking that time is before a certain hour\nof day, or checking that a URL starts with or contains a certain string.\nConditions can be specified down to the attribute level or combined to make\ncomplex calculations, for example - an XACML <Rule> could be created to apply\nthe following policy:
\n\nA store manager is able to amend Product prices only the first of the month,\nand can only alter prices of products she or her immediate superior has\ncreated in the first place
\n
Such a <Rule> would require that the <Condition> includes separate\nclauses/clarifications for the following:
manager)/v2/entities)type must equal Product)As you can see these rules can quickly become very complex. For this initial\nintroduction to XACML, the basic rule set used will be kept as simple as\npossible to avoid unnecessary confusion, suffice it to say that an access policy\nbased on XACML can be expanded to fit the security needs of any complex system.
\nTo keep things simple all components will be run using\nDocker. Docker is a container technology which\nallows to different components isolated into their respective environments.
\nDocker Compose is a tool for defining and running multi-container Docker\napplications. A\nYAML file\nis used configure the required services for the application. This means all\ncontainer services can be brought up in a single command. Docker Compose is\ninstalled by default as part of Docker for Windows and Docker for Mac, however\nLinux users will need to follow the instructions found\nhere
\nWe will start up our services using a simple bash script. Windows users should\ndownload cygwin to provide a command-line\nfunctionality similar to a Linux distribution on Windows.
\nThis application adds level 3 Advanced Authorization security into the existing\nStock Management and Sensors-based application created in\nprevious tutorials and\nsecures access to the context broker behind a\nPEP Proxy. It will make use of\nfive FIWARE components - the\nOrion Context Broker,the\nIoT Agent for UltraLight 2.0,\nthe Keyrock Identity Manager,\nthe Wilma PEP Proxy and the\nAuthzforce XACML Server. All\naccess control decisions will be delegated to Authzforce which will read the\nruleset from a previously uploaded policy domain.
\nBoth the Orion Context Broker and the IoT Agent rely on open source\nMongoDB technology to keep persistence of the\ninformation they hold. We will also be using the dummy IoT devices created in\nthe previous tutorial.\nKeyrock uses its own MySQL database.
\nTherefore the overall architecture will consist of the following elements:
\nSince all interactions between the elements are initiated by HTTP requests, the\nentities can be containerized and run from exposed ports.
\n![\"\"](\"https://fiware.github.io/tutorials.XACML-Access-Rules/img/architecture.png\")
The specific architecture of each section of the tutorial is discussed below.
\nkeyrock:\n image: fiware/idm\n container_name: fiware-keyrock\n hostname: keyrock\n networks:\n default:\n ipv4_address: 172.18.1.5\n depends_on:\n - mysql-db\n - authzforce\n ports:\n - \"3005:3005\"\n environment:\n - DEBUG=idm:*\n - DATABASE_HOST=mysql-db\n - IDM_DB_PASS_FILE=/run/secrets/my_secret_data\n - IDM_DB_USER=root\n - IDM_HOST=http://localhost:3005\n - IDM_PORT=3005\n - IDM_ADMIN_USER=alice\n - IDM_ADMIN_EMAIL=alice-the-admin@test.com\n - IDM_ADMIN_PASS=test\n - IDM_PDP_LEVEL=advanced\n - IDM_AUTHZFORCE_ENABLED=true\n - IDM_AUTHZFORCE_HOST=authzforce\n - IDM_AUTHZFORCE_PORT=8080\n secrets:\n - my_secret_data\nThe keyrock container is a web application server listening on a single port:
3005 has been exposed for HTTP traffic so we can display the web page\nand interact with the REST API.The keyrock container is connecting to Authzforce and is driven by\nenvironment variables as shown:
The other keyrock container configuration values described in the YAML file\nhave been described in previous tutorials
orion-proxy:\n image: fiware/pep-proxy\n container_name: fiware-orion-proxy\n hostname: orion-proxy\n networks:\n default:\n ipv4_address: 172.18.1.10\n depends_on:\n - keyrock\n - authzforce\n ports:\n - \"1027:1027\"\n expose:\n - \"1027\"\n environment:\n - PEP_PROXY_APP_HOST=orion\n - PEP_PROXY_APP_PORT=1026\n - PEP_PROXY_PORT=1027\n - PEP_PROXY_IDM_HOST=keyrock\n - PEP_PROXY_HTTPS_ENABLED=false\n - PEP_PROXY_IDM_SSL_ENABLED=false\n - PEP_PROXY_IDM_PORT=3005\n - PEP_PROXY_APP_ID=tutorial-dckr-site-0000-xpresswebapp\n - PEP_PROXY_USERNAME=pep_proxy_00000000-0000-0000-0000-000000000000\n - PEP_PASSWORD=test\n - PEP_PROXY_PDP=authzforce\n - PEP_PROXY_AUTH_ENABLED=true\n - PEP_PROXY_MAGIC_KEY=1234\n - PEP_PROXY_AZF_PROTOCOL=http\n - PEP_PROXY_AZF_HOST=authzforce\n - PEP_PROXY_AZF_PORT=8080\nThe orion-proxy container is an instance of FIWARE Wilma listening on port\n1027, it is configured to forward traffic to orion on port 1026, which is\nthe default port that the Orion Context Broker is listening to for NGSI\nRequests.
The orion-proxy container is delegating PDP decisions to Authzforce and is\ndriven by environment variables as shown:
The other orion-proxy container configuration values described in the YAML\nfile have been described in previous tutorials
authzforce:\n image: fiware/authzforce-ce-server\n hostname: authzforce\n container_name: fiware-authzforce\n networks:\n default:\n ipv4_address: 172.18.1.12\n ports:\n - \"8080:8080\"\n volumes:\n - ./authzforce/domains:/opt/authzforce-ce-server/data/domains\nThe authzforce container is listening on port 8080, where it receives\nrequests to make PDP decisions. A volume has been exposed to upload a\npre-configured domain so that a set of XACML access control policies has already\nbeen supplied.
tutorial:\n image: fiware/tutorials.context-provider\n hostname: tutorial\n container_name: fiware-tutorial\n networks:\n default:\n ipv4_address: 172.18.1.7\n expose:\n - \"3000\"\n - \"3001\"\n ports:\n - \"3000:3000\"\n - \"3001:3001\"\n environment:\n - \"DEBUG=tutorial:*\"\n - \"WEB_APP_PORT=3000\"\n - \"KEYROCK_URL=http://localhost\"\n - \"KEYROCK_IP_ADDRESS=http://172.18.1.5\"\n - \"KEYROCK_PORT=3005\"\n - \"KEYROCK_CLIENT_ID=tutorial-dckr-site-0000-xpresswebapp\"\n - \"KEYROCK_CLIENT_SECRET=tutorial-dckr-site-0000-clientsecret\"\n - \"CALLBACK_URL=http://localhost:3000/login\"\n - \"AUTHZFORCE_ENABLED=true\"\n - \"AUTHZFORCE_URL=http://authzforce\"\n - \"AUTHZFORCE_PORT=8080\"\nThe tutorial container is listening on two ports:
3000 is exposed so we can see the web page displaying the Dummy IoT\ndevices.3001 is exposed purely for tutorial access - so that cUrl or Postman\ncan make UltraLight commands without being part of the same network.The tutorial container is now secured by Authforce, and is driven by\nenvironment variables as shown:
The other tutorial container configuration values described in the YAML file\nhave been described in previous tutorials
To start the installation, do the following:
\ngit clone git@github.com:Fiware/tutorials.XACML-Access-Rules.git\ncd tutorials.XACML-Access-Rules\n\n./services create\n\n\nNote The initial creation of Docker images can take up to three minutes
\n
Thereafter, all services can be initialized from the command-line by running the\nservices\nBash script provided within the repository:
\n./services start\n\n\n:information_source: Note: If you want to clean up and start over again\nyou can do so with the following command:
\n\n./services stop\n
The following people at test.com legitimately have accounts within the\nApplication
The following people at example.com have signed up for accounts, but have no\nreason to be granted access
Once Authzforce is running, you can check the status by making an HTTP\nrequest to the exposed administration port (usually 8080. If the response is\nblank, this is usually because Authzforce is not running or is listening on\nanother port.
The response returns information about the version of Authzforce.
\n","urlObject":{"protocol":"http","path":["authzforce-ce","version"],"host":["localhost:8080"],"query":[],"variable":[]}},"response":[],"_postman_id":"6b8adac5-0ff6-45aa-9818-22db2d27f438"},{"name":"List all domains","id":"6f24ebcf-eaa2-4a7f-815c-f419d9ab97a7","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"GET","header":[],"url":"http://localhost:8080/authzforce-ce/domains","description":"To request domain information from Authzforce, make a request to the\n/authzforce-ce/domains endpoint.
The response lists the domains which are available in Authzforce. This\ncorresponds to the directory structure uploaded to Authzforce on start-up.
\n","urlObject":{"protocol":"http","path":["authzforce-ce","domains"],"host":["localhost:8080"],"query":[],"variable":[]}},"response":[],"_postman_id":"6f24ebcf-eaa2-4a7f-815c-f419d9ab97a7"},{"name":"Read a single domain","id":"8eba82d9-91bf-4e79-ac0f-66c04f03c229","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"GET","header":[],"url":"http://localhost:8080/authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA","description":"To read information about a domain, and to explore further, make a request to\nthe authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA endpoint. The following request\nobtains information about the gQqnLOnIEeiBFQJCrBIBDA domain, which has been\ngenerated using using a random key by an external Policy Adminstration Point in\nthis case Keyrock has been used as the PAP, and pre-generated the rule sets.
The response lists more information about the domain, including the id used\nwithin Keyrock (tutorial-dckr-site-0000-xpresswebapp)
To list the generated ids for all of the PolicySets found within a domain make a\nrequest to the authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pap/policies endpoint. The\nfollowing request obtains a list of a given policy ids found within the\ngQqnLOnIEeiBFQJCrBIBDA domain.
The response returns a list of available revisions of the given policy which are\navailable within. the Authzforce container. This corresponds the named XML\nfiles 1.xml, 2.xml etc.
To list the available revisions of a policy, make a request to the\nauthzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pap/policies/f8194af5-8a07-486a-9581-c1f05d05483c endpoint.\nAvailable policy id are randomly generated, and can be obtained by drilling down\nusing the previous request. The following request obtains a list revision of a\ngiven policy found within the gQqnLOnIEeiBFQJCrBIBDA domain.
The response returns a list of available revisions of the given policy which are\navailable within the Authzforce container. This corresponds the named XML\nfiles 1.xml, 2.xml etc.
To obtain a single revison of a <PolicySet>, make a request to the\nauthzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pap/policies/f8194af5-8a07-486a-9581-c1f05d05483c/{{revision-number}}\nendpoint. The following request obtains the second revision of the given policy\nfound within the gQqnLOnIEeiBFQJCrBIBDA domain.
The response contains the full <PolicySet> for the given revision. This is a\ncopy of\nthe file\nheld within Authzforce.
A single XACML server can be used to administrate access control policies for\nmultiple applications. Authzforce is implicitly multi-tenant, in that it\nallows separate organizations to work on their policies in isolation from one\nanother. This is done by separating the security policies for each application\ninto a separate domain where they can access their own <PolicySets>. A\ndomain holds meta data about the secured application along with versions of the\npolicies themselves (effectively a series of files which can be accessed by a\nfile server). The domain management API can be used to query Authzforce\nabout the domains served and policies held.
To request a decision from Authzforce, make a POST requets to the\ndomains/{domain-id}/pdp endpoint. In this case the user has the\nmanagers-role-0000-0000-000000000000 and is requesting access the the\n/app/price-change resource.
The managers-role-0000-0000-000000000000 permits access to the\n/app/price-change endpoint. The response for a successful request includes a\n<Decision> element to Permit access to the resource.
To request a decision from Authzforce, make a POST requets to the\ndomains/{domain-id}/pdp endpoint. In this case the user has the\nsecurity-role-0000-0000-000000000000 and is requesting access the the\n/app/price-change resource.
The security-role-0000-0000-000000000000 does not permit access to the\n/app/price-change endpoint. The response for an unsuccessful request includes\na <Decision> element which will Deny access to the resource.
For the purpose of this tutorial, Authzforce has been just been supplied\nwith a simple set of basic role-based rules in a similar fashion to the level 2\nauthorization example found in the previous Securing Access tutorial:
\nThe only difference is that access to all store entities is now restricted to\nusers with an assigned role rather than being based on level 1 authentication\naccess.
\nTo request a decision from Authzforce, a structured request containing all\nrelevant information must be sent to the domains/{domain-id}/pdp endpoint. In\nthis case, the Body of the request includes information such as the roles that\nthe User has, the application id that is being requested\n(tutorial-dckr-site-0000-xpresswebapp) and the HTTP verb and resource that are\nbeing requested ( a GET request on the /app/price-change URL). Obviously the\ninformation passed in the Body can be expanded as the rules become more complex.
base64 concatenation of Client Id and Client Secret
\n"},{"key":"Content-Type","value":"application/x-www-form-urlencoded"},{"key":"Accept","value":"application/json"}],"body":{"mode":"raw","raw":"username=bob-the-manager@test.com&password=test&grant_type=password"},"url":"http://localhost:3005/oauth2/token","description":"In order to identify themselves, every user must obtain an access token, in\norder to do so, they must use one of the OAuth2 access grants described in a\nprevious tutorial.
\nTo log in using the user-credentials flow send a POST request to the\noauth2/token endpoint of Keyrock with the grant_type=password
The response returns an access_token to identify the user (in this case Bob\nthe Manager)
If a user has logged in, the access_token can be used in combiniation with the /user endpoint\nto obtain access permissions to a resouce. This example retrieves Bobs's permissions to a given\nresource.
Where :
\n{{access-token}} is the current access token of a logged in user (e.g.\n08fef363c429cb34cfff3f56dfe751a8d1890690)tutorial-dckr-site-0000-xpresswebapp holds the application to request\ntutorial-dckr-site-0000-xpresswebapp and authzforce=true indicates that\nwe want to obtain an Authzforce Domain from KeyrockThe response include an authorization_decision attribute which denies direct\naccess for the request, but includes additional information so that an\nadditional request a decision from Authzforce
In the example below the access token used belonged to Bob the manager, and his\nroles and the app_azf_domain associated to the app-id are returned.
To request a decision from Authzforce, a structured request containing all\nrelevant information must be sent to the domains/{domain-id}/pdp endpoint. In\nthis case, the Body of the request includes information such as the roles that\nthe User has (managers-role-0000-0000-000000000000), the application id that\nis being requested (tutorial-dckr-site-0000-xpresswebapp) and the HTTP verb\nand resource that are being requested ( a POST request on the /v2/entities\nURL)
The response includes a <Decision> element which will either Permit or\nDeny the request.
As a reminder, there are three Levels of PDP Access Control:
\nWithin FIWARE, Level 3 access control can be provided by adding Authzforce\nto the existing security microservices (IDM and PEP Proxy) within the Smart\nApplication infrastructure. Access control levels 1 and 2 have been covered in\nprevious tutorials and\ncan be fulfilled using Keyrock alone or with or without an associated PEP\nProxy.
\nAdvanced Authorization is able to deal with complex rulesets. Permissions are no\nlonger merely based on a fixed role, resource and an action, but can be extended\nas necessary.
\nFor example users in role XXX can access URL starting with YYY provided\nthat the HTTP verb is either GET, PUT or POST. Such users may also\nDELETE provided that they were the creator in the first place.
Within the tutorial programatic example we are using our own trusted instance of\nKeyrock - once a user has signed in and obtained an access_token, the\naccess_token can be stored in session and used to retrieve user details on\ndemand. All access to the Orion context broker is hidden behind a PEP Proxy.\nWhenever a request is made to Orion, the access_token is passed in the header\nof the request, and the PEP proxy handles the decision to whether to execute the\nrequest.
Programmatically, any Policy Execution Point consists of two parts, an oAuth\nrequest to Keyrock retrieves information about the user (such as the assigned\nroles) as well as the policy domain to be queried.
\nA second request is sent to the relevant domain endpoint within Authzforce,\nproviding all of the information necessary for Authzforce to provide a\njudgement. Authzforce responds with a permit or deny response, and the\ndecision whether to continue can be made thereafter.
\nfunction authorizeAdvancedXACML(req, res, next, resource = req.url) {\n const keyrockUserUrl =\n \"http://keyrock/user?access_token=\" +\n req.session.access_token +\n \"&app_id=\" +\n clientId +\n \"&authzforce=true\";\n\n return oa\n .get(keyrockUserUrl)\n .then(response => {\n const user = JSON.parse(response);\n return azf.policyDomainRequest(\n user.app_azf_domain,\n user.roles,\n resource,\n req.method\n );\n })\n .then(authzforceResponse => {\n res.locals.authorized = authzforceResponse === \"Permit\";\n return next();\n })\n .catch(error => {\n debug(error);\n res.locals.authorized = false;\n return next();\n });\n}\nThe full code to supply each request to Authzforce can be found within the\ntutorials'\nGit Repository -\nthe actual information to supply will depend on business use case - it could be\nexpanded to include temporal information, relationships between records and so\non, but in this very simple example only roles are necessary.
\nconst xml2js = require(\"xml2js\");\nconst request = require(\"request\");\n\nfunction policyDomainRequest(domain, roles, resource, action) {\n let body =\n '<?xml version=\"1.0\" encoding=\"UTF-8\"?>\\n' +\n '<Request xmlns=\"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17\" CombinedDecision=\"false\" ReturnPolicyIdList=\"false\">\\n';\n // Code to create the XML body for the request is omitted\n body = body + \"</Request>\";\n\n const options = {\n method: \"POST\",\n url: \"http://authzforceUrl/authzforce-ce/domains/\" + domain + \"/pdp\",\n headers: { \"Content-Type\": \"application/xml\" },\n body\n };\n\n return new Promise((resolve, reject) => {\n request(options, function(error, response, body) {\n let decision;\n xml2js.parseString(\n body,\n { tagNameProcessors: [xml2js.processors.stripPrefix] },\n function(err, jsonRes) {\n // The decision is found within the /Response/Result[0]/Decision[0] XPath\n decision = jsonRes.Response.Result[0].Decision[0];\n }\n );\n decision = String(decision);\n return error ? reject(error) : resolve(decision);\n });\n });\n}\nApplying advanced authorization within a PEP proxy requires very similar code to\nthe programmatic example described above. The Wilma generic enabler extracts\na token from the header supplied by the request and makes a request to\nKeyrock to obtain further information about the user. A PDP request is then\nmade to Authzforce to decide whether to procede.
\nObviously any scalable solution should also cache information about the PDP\nrequests made and the responses to avoid making unnecessary requests.
\n\n\nNote Five resources have been secured at level 3:
\n\n
\n- sending the unlock door command
\n- sending the ring bell command
\n- access to the price-change area
\n- access to the order-stock area
\n- access to Orion (behind a PEP Proxy)
\n
Eve has an account, but no roles in the application.
\n\n\nNote As Eve has a recognized account, she gains full authentication\naccess. This means she is able to view the Store page, even though her\naccount has no roles attached.
\n
http://localhost:3000, log in as eve@example.com with the password\ntestClick on any store page - access to view the page is permitted for any\nlogged in users, however access to retrieve Orion data is now denied\nsince Eve has no role which permits access.
\nClick on the restricted access links at http://localhost:3000 - access is\ndenied
Open the Device Monitor on http://localhost:3000/device/monitor
Bob has the management role
\nhttp://localhost:3000, log in as bob-the-manager@test.com with the\npassword testhttp://localhost:3000 - access is\npermitted - This is a management only permissionhttp://localhost:3000/device/monitorCharlie has the security role
\nhttp://localhost:3000, log in as charlie-security@test.com with the\npassword testhttp://localhost:3000 - access is\ndenied - This is a management only permissionhttp://localhost:3000/device/monitor