Goal
To be comfortable with adding seed data for custom security permissions and configuration to manage relationships and allocate security permissions when registering a super hero as well as privacy instructions to protect certain data.
Starting code
Start tag: lesson/12
Requirements
Apply the security permissions to the super hero registration and view business services as per Table 12.1 below. The user who registers the super hero gaining the relevant security permission relationship should also result in the registered super hero appearing in their My Portfolio section within their dashboard when completed.
| Security permission | Assignment rules | Super hero functions or actions rules |
|---|---|---|
| PERM_SHP001_REGISTER_SUPER_HERO_DATA | All logged in users | Can register a super hero |
| PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA | Any logged in or guest user | (Basic) Can view basic information |
| PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA | The user who registers the super hero and any confidants or sidekicks associated with a Verne user account* | (Private) Can view all but the most private of information e.g. weaknesses |
| PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA | The user who registers the super hero | (Restricted) Can view all information |
| PERM_SHP005_ACCESS_MAINTAIN_SUPER_HERO_DATA | The user who registers the super hero and any confidants associated with a Verne user account* | Can perform maintenance functions, maintaining data the user has access to (based on the above permissions) |
* Note: Roles associated to a Verne user account are not covered in this lesson.
Additionally, the following data is considered restricted when viewing super hero data. The value in the second column relates to the name in brackets in the last column for the view-related rows 3 & 4 in Table 12.1 above. Anything not included in the table below is considered accessible to all levels including "Basic".
| Data | Restricted access level |
|---|---|
| Super hero secret identities | Restricted |
| Super hero registration date | Private |
| Super hero year of arrival | Private |
| Super hero super powers | Private |
| Confidants | Restricted |
| Sidekicks | Private |
| Sidekick type | Restricted |
Steps
A little light reading about security permissions in general and then security permission pools, groups, users and teams more specifically is a good idea before diving into this lesson. Feel free to come back to any of these as the lesson progresses and gives more context to these concepts.
Restricted access configuration
Kind of like test driven development, we’ll configure the restrictions first and check that we can’t access relevant actions or data. Then we’ll add in the security permissions and any configuration to link this to users in order to check that we then can access things as expected.
Registration business service
Based on Table 12.1 above only users with the "PERM_SHP001_REGISTER_SUPER_HERO_DATA" security permission should be able to register a super hero. We can easily implement this restriction by updating our <securityPermission/> element on the "heroRegister" business service. In fact, we no longer treat internal and external users differently – they either have this permission or they don’t (even though internal and external users may get that permission via a different means). This means both of the existing securityPermission elements can be replace with the single following one:
<securityPermission permission="PERM_SHP001_REGISTER_SUPER_HERO_DATA"/>You should now notice that the "Register a Super Hero" menu is no longer available in the application, since no user has the "PERM_SHP001_REGISTER_SUPER_HERO_DATA" permission yet.
View business service
Viewing a super hero’s details at any level is restricted to those with the security permission "PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA", so similar to "heroRegister" we can restrict the "heroView" business service with this permission. We’ll leave that for you to do unassisted ?
Once done you’ll notice you can no longer view a super hero, either from a link on the dashboard or via the super hero search results. Before we continue on with restricting specific details when viewing the super hero as per Table 12.2 above, we’ll update our application so we have the relevant security permission and are able to view super heroes again.
Security permissions
Now let’s turn our attention to whether the related security permissions exist in our application and are allocated as expected. Let’s do a quick search to see if any of the permissions mentioned in Table 12.1 above exist in the application. Searching for "PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA" using Ctrl+Shift+F for example doesn’t return any permission definition results. The same is true for the other permissions too, which means we’ll have to add them.
Seeding security permissions
The seeding security data documentation outlines how we might go about adding in our required security permissions. It means a combination of some <seed/> elements configured in the security application.xml combined with a Groovy resource for performing the seeding, which itself makes use of a CSV file which lists the security data to add. We’ll start at the back of this train and add our CSV file.
It’s often easier to add the content of these sorts of files based off a similar existing example rather than starting from scratch, so go ahead and open up the permissions_security.csv file (using Ctrl+Shift+N) and have a look at it’s content and what information is provided.
Create a new CSV file resource called permissions_super_heroes.csv in the super hero "security" application’s space in a new "resources/seed/serviceTransactions" folder. To do this, you can right click on the security folder and add a new resource of type ‘Plain File’ in the appropriate folder. Then have a go at filling out some of it’s details (the "System name" column for example) but as it can be quite wordy and detailed, an example of what might be used for the file’s full details are provided below.
Code,Name,System name,Permission sets,Description
SHP001,"Register a new super hero",PERM_SHP001_REGISTER_SUPER_HERO,"Create entity, Super heroes","Register a super hero"
SHP002,"Access basic super hero data",PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA,"View entity, Data privacy, Read only, Super heroes","Access basic super hero data"
SHP003,"Access most super hero data, all but the most highly sensitive details",PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA,"View entity, Data privacy, Read only, Super heroes","Access most super hero data, all but the most highly sensitive details"
SHP004,"Access all super hero data, including highly sensitive details",PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA,"View entity, Data privacy, Read only, Super heroes","Access all super hero data, including highly sensitive details"
SHP005,"Maintain super hero data that they have access to",PERM_SHP005_ACCESS_MAINTAIN_SUPER_HERO_DATA,"Maintain entity (external), Super heroes","Maintain super hero data they have access to"Now we need the Groovy resource to make use of this CSV file. For that add a permissions_super_heroes.groovy file in the same location as the CSV file of the same name. For this we’ll simply have the following (note: almost an identical copy of the permissions_security.groovy file’s content minus the comments).
import com.fostermoore.catalyst.ng.blade.context.ApplicationContext
import com.fostermoore.catalyst.registry.module.security.resources.ext.security.Support
return Support.csvSecurityPermissions(ApplicationContext.get().application.getResource("/seed/serviceTransactions/permissions_super_heroes.csv"))Note the reference to the CSV file we just added which explains why the format, i.e. columns, need to be the ones used and in the specific order so it conforms to the format expected of the CSV file passed to the Support.csvSecurityPermissions method called. You can confirm this by looking at this method in the resources/ext/security/Support.groovy file. Note that it returns a list of ServiceTransaction objects and these relate to "Permission" root domains with data representing the applicable security permissions to be added – in our case with a number of details from the CSV file contents.
You could of course initialise these service transactions without making use of the existing Support.groovy file or the csvSecurityPermissions method, instead using custom code either entirely within the permissions_super_heroes.groovy file or calling some other resource(s). The main thing is ending up with a list of ServiceTransaction objects containing the data you want to seed security permissions for.
Seed configuration
Now we have the CSV file with the security permission details and the Groovy file that references it, so now all we need is the configuration that includes the Groovy resource. We do this by adding it to the <application/> configuration for the application we want it added to. Now you may be thinking this is the super heroes application itself, and while it’s true that these security permissions very much relate to the super heroes application, it’s actually the security application relating to the super heroes register that we’re interested in. It’s security data after all. So we add the add the following configuration to the security application.xml file. You’ll notice there are already a bunch of <seed/> elements present that provide the underlying security seed data used and required by most registers. The group can be used to restrict which environments this seeded data is added to. In our case, we want the permissions in all our environments, so we’ll go with *.
<seed group="*" resourceName="seed/serviceTransactions/permissions_super_heroes.groovy"/>Restart the application
Even with this configuration added, due to the way data is seeded an application restart will need to happen in order for the change to take effect. So do this now and see what happens.
Not much! We still can’t access the super hero registration or view business services… why is that? ?
First confirm the security permissions are in fact now present in the application using the Service Transaction Repository in the System Administration console as per Fig 12.1 below.
Updating guest & logged in user permission pools
While the security permissions exist in our application now, they’re not assigned to any users. Looking at Table 12.1 we can see from the first row that security permission "PERM_SHP001_REGISTER_SUPER_HERO_DATA" should be associated to all logged in users and from the second row that the "PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA" security permission should be associated to any user at all, logged in or not.
Permissions based on whether a user is logged in or not point towards using permission pools as the means of associating the security permission. Guest user and logged in external user security permission pools are common in Verne so can be used for this purpose. Open the permission_pools_core.csv file to see these being defined and the security permissions associated to them. What we want to do is to update these to include our related super hero security permissions.
Copy the permission_pools_core.csv and permission_pools_core.groovy files and paste them into the "security" application space’s resources/seed/serviceTransactions/ folder, renaming them to permission_pools_super_heroes.csv and permission_pools_super_heroes.groovy respectively.
You can use the ‘Sync to source’ bullseye icon above the tree to find the file in the Magellan treeview if you have permission_pools_core.csv open in the editor pane and from there do a manual copy paste or you can right click and override and choose the security application as the increment. You still need to do the rename manually though.
Add the "PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA" to the CSV list of permissions at the end of the security permission pool line relating to guest users (i.e. the line with a code of PP01). Do similarly for the pool relating to external logged in users (the line with code PP02) but add both the "PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA" and "PERM_SHP001_REGISTER_SUPER_HERO_DATA" permissions, separated by a comma. This should give you a file like the following.
Code,Name,Description,Permission system name
PP01,Guest user,"Guest user inherits all permissions listed in this pool as well as access associated with permission SP001 Guest user","PERM_COP001_ACCESS_PUBLIC_DATA_COMPANY,PERM_COP002_ACCESS_PUBLIC_DATA_NAME_RESERVATION,PERM_COP500_VIEW_DETAILS_COMPANY,PERM_COP501_VIEW_DETAILS_COMPANY_NAME_RESERVATION,PERM_COP502_GENERATE_EXTRACT_CERTIFICATE_COMPANY,PERM_COP701_COMPANIES_PUBLIC_SEARCH,PERM_P110_VIEW_ENTITY_FILINGS_HISTORY,PERM_PRP001_ACCESS_PUBLIC_DATA_PROFESSIONAL,PERM_PRP404_GENERATE_EXTRACT_CERTIFICATE_PROFESSIONAL,PERM_PRP500_VIEW_DETAILS_PROFESSIONAL,PERM_PRP701_PROFESSIONALS_PUBLIC_SEARCH,PERM_P230_CREATE_MY_EXTERNAL_USER_PROFILE,PERM_P229_ACTIVATE_MY_INTERNAL_USER_PROFILE,PERM_P227_GUEST_USER_LANDING_PAGE,PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA"
PP02,External registered user,"External logged on user inherits all permissions listed in this pool as well as access associated with permission SP002 External registered user. Also external registered user might inherit one or more relationship pools listed below if they have active entity relationships.","PERM_COP001_ACCESS_PUBLIC_DATA_COMPANY,PERM_COP002_ACCESS_PUBLIC_DATA_NAME_RESERVATION,PERM_COP300_REGISTER_COMPANY,PERM_COP301_RESERVE_COMPANY_NAME,PERM_COP403_LODGE_COMPANY_GENERAL_DOCUMENT,PERM_COP500_VIEW_DETAILS_COMPANY,PERM_COP501_VIEW_DETAILS_COMPANY_NAME_RESERVATION,PERM_COP502_GENERATE_EXTRACT_CERTIFICATE_COMPANY,PERM_COP701_COMPANIES_PUBLIC_SEARCH,PERM_P110_VIEW_ENTITY_FILINGS_HISTORY,PERM_P410_PAY_BY_CREDIT_CARD,PERM_P411_PAY_BY_DEPOSIT_ACCOUNT,PERM_P413_PAY_BY_CHEQUE,PERM_PRP001_ACCESS_PUBLIC_DATA_PROFESSIONAL,PERM_PRP300_REGISTER_PROFESSIONAL,PERM_PRP404_GENERATE_EXTRACT_CERTIFICATE_PROFESSIONAL,PERM_PRP500_VIEW_DETAILS_PROFESSIONAL,PERM_PRP701_PROFESSIONALS_PUBLIC_SEARCH,PERM_P248_VIEW_MY_ORGS_LIST,PERM_P249_CREATE_MY_ORG,PERM_P247_JOIN_MY_ORG,PERM_P233_ACCESS_EXTERNAL_USER_DASHBOARD,PERM_P305_ACCESS_DESIGN_SYSTEM,PERM_P306_ACCESS_OPEN_API,PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA,PERM_SHP001_REGISTER_SUPER_HERO"Update the permission_pools_super_heroes.groovy file to reference this new CSV file, but also add "replace" as the seedOperation argument as shown below. This ensures the security permission pools, which already exist, are re-seeded when the application starts up again.
import com.fostermoore.catalyst.ng.blade.context.ApplicationContext
import com.fostermoore.catalyst.registry.module.security.resources.ext.security.Support
return Support.csvSecurityPermissionPools(ApplicationContext.get().application.getResource("/seed/serviceTransactions/permission_pools_super_heroes.csv"), "replace")As the final step, remove the <seed/> element in the "security" application’s application.xml file that references the now superseded permission_pools_core.groovy and add one that references our new permission_pools_super_heroes.groovy one instead. OK, now let’s restart the application again and see if that did the job.
We’re back in business! The Register a Super Hero menu item now appears as per Fig 12.2 above when logged in, similarly you can view a registered super hero’s details again too (confirm this via the application).
Privacy instructions
Now that we can access the registration and view services again it’s time to look at the specific sections of the view form restricted as per Table 12.2 above. How will we restrict those sections? This is where privacy instructions can be useful.
Privacy instructions allow you to configure rules for what security permissions are required in order to access certain data within a service instance’s view tree form. Sound like the sort of thing we’re after? Indeed! Add a privacyInstructions.xml resource in the super heroes application space, then have a look at the available options and documentation to get a feel for how they might work.
Looking at the first row in Table 12.2 we should only allow the super hero identities child-domain to be visible when a user has the "PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA" security permission. So we’ll add a <privacyInstruction/> element with a name of "superHeroRestricted" and a <privacyScope/> that excludes the child IndividualName domain. Have a go then check against the configuration below.
<privacyInstruction name="superHeroRestricted">
<privacyScope service="heroView" requiredPermissions="PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA" action="exclude" domain="IndividualName"/>
</privacyInstruction>The second row in Table 12.2 relates to security permission "PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA" and a single attribute, RegistrationDate, as opposed to an entire domain. So we can target this with another <privacyScope/> element, this time using the "attribute" attribute with a value of – you guessed it – RegistrationDate. This gives us the following updated privacy instruction.
<privacyInstruction name="superHeroRestricted">
<privacyScope service="heroView" requiredPermissions="PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA" action="exclude" domain="IndividualName"/>
<privacyScope service="heroView" requiredPermissions="PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA" action="exclude" attribute="RegistrationDate"/>
</privacyInstruction>Now have a go at adding the remaining privacy instruction configuration based on rows 3-5 of Table 12.2, before comparing with the following (note: they’ve been reordered by security permission so they align more).
<privacyInstruction name="superHeroRestricted" rootDomain>
<privacyScope service="heroView" requiredPermissions="PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA" action="exclude" domain="IndividualName"/>
<privacyScope service="heroView" requiredPermissions="PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA" action="exclude" domain="Confidant"/>
<privacyScope service="heroView" requiredPermissions="PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA" action="exclude" domain="Sidekick" attribute="Type"/>
<privacyScope service="heroView" requiredPermissions="PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA" action="exclude" attribute="RegistrationDate"/>
<privacyScope service="heroView" requiredPermissions="PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA" action="exclude" attribute="YearOfArrival"/>
<privacyScope service="heroView" requiredPermissions="PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA" action="exclude" domain="SuperPower"/>
<privacyScope service="heroView" requiredPermissions="PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA" action="exclude" domain="Sidekick"/>
</privacyInstruction>Now, when we view a super hero, we can’t see any of the details we’ve restricted via the privacy instructions. For example there is no Year of Arrival or Registration Date on the general details tab, as per Fig 12.3 below.
Private sub-domain display tweaks
So the privacy instructions work pretty seamlessly for attributes, but what about the ones targeting domains like the secret identity IndividualName domain, or the confidants and sidekick domains? The secret identity name is already covered when viewing the super hero based on the rule to only show the repeater if there is a secret identity name to show, implemented by the following tag on the repeater within the HeroDetails component.
<platform:set-property visible="false" when-service-mode="View" when-has-active-children="false"/>When it comes to the privacy-restricted confidants and sidekicks however, while they’re excluded – i.e. the data is protected – they display the same as if you had authority to view them but there were no confidants or sidekicks associated to the super hero, as shown in Fig 12.4 below.
What we really want is for these tabs to not show at all if the user does not have the appropriate security permission. This is different from the scenario where there are no confidants or sidekicks to show when someone has permission to view them, which is valid, so a rule to hide the confidants or sidekicks repeaters if there are no records, as per the secret identity repeater, doesn’t really work. Besides, we’d still have the tab shown with blank content. Not ideal. Instead we add the rule shown below to the entire confidants tab section in the "heroView" form, as well as a similar one using the "PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA" security permission for the sidekicks tab.
<platform:set-property visible="false" when-user-does-not-have-permission="PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA"/>With these rules we now have the tabs excluded entirely from the super hero view when the user does not have these permissions, as per Fig 12.5 below.
These rules kind of supersede the privacy instructions for the confidants and sidekicks. In other words, without the appropriate security permissions you still wouldn’t see the confidants or sidekicks even if they were excluded from the privacy instructions. This highlights that <privacyInstructions/> are not a silver bullet for satisfying all requirements from a UI/display perspective, however, they do mean that specified data is protected regardless of the UI, so are worthwhile to include even if additional display tweaks are required. They can be thought of as the last line of defence that won’t be breached regardless of the form configuration. This is highlighted in the documentation on the limitations of privacy instructions.
Entity based permissions
We now have our security permissions in place and the relevant ones associated to the guest and logged in security permission pools, as well as privacy instructions and rules to restrict data based on those security permissions. What we don’t have yet is the association of the "PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA" security permisson to the user who registers the super hero, specified in row four of Table 12.1. This rule is not a based on a general logged in state, nor does it apply across an application in some way – it is specific to a registered super hero and a Verne user account (the logged in user’s) – it is based on a relationship between the two.
Relationship instructions
The easiest way to create a relationship between some registry data and a user account in Verne is to use relationship instructions. Similar to privacyInstructions.xml, create a relationshipInstructions.xml resource in the super heroes application space, add the <relationshipInstructions/> and a child <relationshipInstruction/> element and have a look at the available options and documentation to get a feel for how they might work.
Have a go at configuring the relationship instruction with the following:
- Restrict the instruction to only apply to service transactions with a rootDomainName of “Hero”
- Use “Owner” as the value for the “RelationshipName” attribute on the resulting Relationship domain
- Only have the instruction apply to external users
- Set the scope to apply to “Create” service instances only so it only applies to super hero registration
- Set the scope to be based on the initiator of service, rather than any role (or other) data within the form
This should give you something similar to the following.
<relationshipInstruction name="superHeroOwner" relationshipName="Owner" rootDomainName="Hero" skipForInternal="true">
<relationshipScope serviceMode="Create" matchType="initiator"/>
</relationshipInstruction>Add relationship security pool
A security permission pool is used to associate security permissions via a relationship, rather than the permissions directly. The only thing left to add now is the security permission pool that provides the security permissions associated with the relationship.
We can simply add an extra line to our existing permission_pools_super_heroes.csv file for the super hero owner relationship that includes the security permissions we want them to have. We’ll call this pool "PP03" and we’ll include the permissions as per rows 3-5 in Table 12.1. Note: they will still get the permission from row two based on just being logged in as well, since this is handled via a separate pool they also qualify for. Once done the permission_pools_super_heroes.csv content should look as per the following.
Code,Name,Description,Permission system name
PP01,Guest user,"Guest user inherits all permissions listed in this pool as well as access associated with permission SP001 Guest user","PERM_COP001_ACCESS_PUBLIC_DATA_COMPANY,PERM_COP002_ACCESS_PUBLIC_DATA_NAME_RESERVATION,PERM_COP500_VIEW_DETAILS_COMPANY,PERM_COP501_VIEW_DETAILS_COMPANY_NAME_RESERVATION,PERM_COP502_GENERATE_EXTRACT_CERTIFICATE_COMPANY,PERM_COP701_COMPANIES_PUBLIC_SEARCH,PERM_P110_VIEW_ENTITY_FILINGS_HISTORY,PERM_PRP001_ACCESS_PUBLIC_DATA_PROFESSIONAL,PERM_PRP404_GENERATE_EXTRACT_CERTIFICATE_PROFESSIONAL,PERM_PRP500_VIEW_DETAILS_PROFESSIONAL,PERM_PRP701_PROFESSIONALS_PUBLIC_SEARCH,PERM_P230_CREATE_MY_EXTERNAL_USER_PROFILE,PERM_P229_ACTIVATE_MY_INTERNAL_USER_PROFILE,PERM_P227_GUEST_USER_LANDING_PAGE,PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA"
PP02,External registered user,"External logged on user inherits all permissions listed in this pool as well as access associated with permission SP002 External registered user. Also external registered user might inherit one or more relationship pools listed below if they have active entity relationships.","PERM_COP001_ACCESS_PUBLIC_DATA_COMPANY,PERM_COP002_ACCESS_PUBLIC_DATA_NAME_RESERVATION,PERM_COP300_REGISTER_COMPANY,PERM_COP301_RESERVE_COMPANY_NAME,PERM_COP403_LODGE_COMPANY_GENERAL_DOCUMENT,PERM_COP500_VIEW_DETAILS_COMPANY,PERM_COP501_VIEW_DETAILS_COMPANY_NAME_RESERVATION,PERM_COP502_GENERATE_EXTRACT_CERTIFICATE_COMPANY,PERM_COP701_COMPANIES_PUBLIC_SEARCH,PERM_P110_VIEW_ENTITY_FILINGS_HISTORY,PERM_P410_PAY_BY_CREDIT_CARD,PERM_P411_PAY_BY_DEPOSIT_ACCOUNT,PERM_P413_PAY_BY_CHEQUE,PERM_PRP001_ACCESS_PUBLIC_DATA_PROFESSIONAL,PERM_PRP300_REGISTER_PROFESSIONAL,PERM_PRP404_GENERATE_EXTRACT_CERTIFICATE_PROFESSIONAL,PERM_PRP500_VIEW_DETAILS_PROFESSIONAL,PERM_PRP701_PROFESSIONALS_PUBLIC_SEARCH,PERM_P248_VIEW_MY_ORGS_LIST,PERM_P249_CREATE_MY_ORG,PERM_P247_JOIN_MY_ORG,PERM_P233_ACCESS_EXTERNAL_USER_DASHBOARD,PERM_P305_ACCESS_DESIGN_SYSTEM,PERM_P306_ACCESS_OPEN_API,PERM_SHP002_ACCESS_PUBLIC_SUPER_HERO_DATA,PERM_SHP001_REGISTER_SUPER_HERO"
PP03,Super hero owner,"The user/organisation profile linked with a super hero registration they initiated","PERM_SHP003_ACCESS_PRIVATE_SUPER_HERO_DATA,PERM_SHP004_ACCESS_RESTRICTED_SUPER_HERO_DATA,PERM_SHP005_MAINTAIN_SUPER_HERO_DATA"Add "PP03" as the "permissionPool" attribute to the <relationshipInstruction/>, restart the application so the security permission pool is seeded then register a new super hero to see if the owner relationship gets applied. We can check this by viewing the newly registered super hero and seeing whether you can now see the private and restricted details too, as shown in Fig 12.6 below. Sign in as another user (e.g. External02@fostermoore.com/External01) to check non-owners still only see the publicly available information too.
And that, ladies and gentlemen, is pretty much another lesson done and dusted ? Check out the wrap up section below and be on your merry way… 🙂
Wrap up
This lesson covered security permissions, data privacy and relationships for
- Some reading up on security permissions
- Restricting access to a business service based on the
<securityPermission/>element - How to seed security permissions data
- Updating the guest user and logged in external user security permission pools to include the new security permissions
- Adding privacy instructions to restrict access to data
- Limitations of privacy instructions in certain views and using the
<platform:set-property/>tag with a user-permission-related option to tweak the display, even though the data is already fully protected by the privacy instructions - Using relationship instructions to add grant permissions to a user in relation to a specific entity
- Adding a new security permission pool to manage user security defined by the relationship
