"The people affected by the role hierarchy change operation are evaluated against
all applicable policies in the system, including policies that are not related to any
of the parent roles. As a result, you might find accounts not related to the role
hierarchy change that are being enforced."
Can someone explain in layman's term what exactly the above lines are trying to convey, like :
when does a role hierarchy change operation occur ?
what are the applicable policies here and how will change be evaluated ?
You have just the above part from a longer chapter and it sounds a little bit out of context, but it is not that complicated.
Role hierarchies have to do with relationships between roles. In ITIM/ISIM you can define that roles are parents/children of other roles and thus create hierarchies. It also supports that notion of inheritance, so that for example Provisioning policies that apply to the Parent role, apply to the children roles as well.
A role hierarchy change happens when you add a parent or a child in a given role. If for example you had Role1 and you a provisioning policy that applies to this role, when you add Role2 as a child of the Role1 role, then the provisioning policy will now apply to Role2 too.
As for the other matter in discussion, lets start with two facts :
You might have a number of provisioning policies in your system. Depending on how the policy membership is set up, each one of those can apply to specific roles, groups, or all the persons in your system.
In the default ITIM configuration, each time you modify a person, the modifyPerson workflow is executed. This can contain a number of nodes, but by default it contains a modifyPerson node and an enforcePolicy node. The modifyPerson performs, as the name implies, the modifications on the person object in ITIM. The enforcePolicy node, again as the name implies, evaluates ALL applicable provisioning policies for the person and performs the necessary actions on the persons accounts according to the provisioning policies.
What the sentence you quoted says is that when you add a role (RoleA) as a child of another role (RoleB), the provisioning policy (lets call it Policy1 ) that applies to RoleA, now applies to RoleB also. And if you had a person that was member of the RoleB, now that you perform the role hierarchy change, the policies for this person will be evaluated because ITIM needs to enforce Policy1 for him. However this does not mean that at this time, the only policy that applies to this person, is Policy1. A number of different policies can apply to him and ALL of them will be evaluated at this time. This can lead to changes in other accounts or more changes in the same account of this person.
By the way, this has been modified a little bit with ISIM 6 , FixPack 3, Intermittent FixPack 11. Now the enforce policy node in the workflow can be configured to only take into consideration the provisioning policies that need to be reevaluated for the specific change that happens and not blindly go through and evaluate everything again.
Related
In a B2B blockchain network, is "Participant" meant to represent the business or the person that acts on behalf of the business (e.g. an employee) or both?
In most of the examples that I have seen, "Participant" seems to represent the business. But once you start thinking about security and Participant-Identity mapping, "Participant" as a person makes more sense.
Regards,
Naveen
In Hyperledger Composer, your 'active' Participant (or 'a' participant) may operate at a transactional level, in that it uses an identity to perform actions (adding assets, submitting transaction(s) that update those assets, query execution etc) - and needs at least one identity associated with it, to execute such transactions. At an Hyperledger Composer level, that Participant can be a person, or (if so implemented by the author's use case) it can be represented as a participant entity eg. Payroll Administrator (and still have an identity or identities mapped to it). Think for example also, of needing access control - who can see what at a Participant level? In Hyperledger Composer, one participant can have multiple identities - but only one is submitted (as an identity signature) with a transaction at a time.
Now from a 'business' perspective (irrespective to any Composer context) a business (organisation) can also 'participate' in a business network as a 'party' (so, a complex network of companies, working together to accomplish certain goals and have a business relationship with each other, narrowed down to specific business flows). To implement this on a blockchain, the parties will want to reduce this down to a level where identities and participants (and all the other elements of the modeled network) are defined in the network they join. So really, its just a question of context, and I think you'll now see what modeling and using a Participant in Hyperledger Composer means, and the outer context.
Participant: Participants represent the organizations or people who take part in the digital business network. Participants are defined in the business network model.
https://hyperledger.github.io/composer/latest/reference/glossary.html
And: https://hyperledger.github.io/composer/latest/managing/participantsandidentities.html
I have an aggregate root that needs to be in valid state in order to be used in the system properly. However, the process of building the aggregate is long enough for users to be distracted. Sometimes, all user wants is to configure some part of this big aggregate and then save his work and go home, and tomorrow he will finish aggregate construction.
How can I do this? My PM enforced that we allow aggregates to have invalid state, and then we will check IsValid boolean right before we use it.
I personally went another path: I used Builder pattern for building my aggregate and now I'm planning to persist the builder itself as some intermediary state.
I have an aggregate root that needs to be in valid state in order to be used in the system properly. However, the process of building the aggregate is long enough for users to be distracted. Sometimes, all user wants is to configure some part of this big aggregate and then save his work and go home, and tomorrow he will finish aggregate construction.
How can I do this?
You have two aggregates -- one is the "configuration" that the users can edit at their own pace. The other is the live running instance built from a copy of the configuration, but only if that configuration satisfies the invariant of the running instance.
By the way, there can be a situation where the "running" aggregate
should be edited again (in fact, this is frequent). Then it can become
invalid again.
You have two obvious options here:
Model every undergoing creation/change process as a different aggregate (perhaps even in a different Bounded Context -- could be CRUD). That allows you to free your main aggregate from contextual validation.
Use the same aggregate instance, but in different states. For instance, you may have some fields as Optional<T> which could be empty when the aggregate is in the draft state, but can't when it is published. The state pattern could possibly be useful here.
I was thinking to create an application (in C/C++ or C# - I am not sure yet) which has to track some changes that took place only for the user accounts from an Organization Unit (for example: a user account which is a member of "A" OU has been deleted). I have read something about: subscribing to events in event log but it seems that in this case I will receive informations about every user account which has been deleted for example. Using this method it seems that I will have to check if that user is part of my OU.
Another method that I have in mind involves the using of "Polling for changes using DirSync". It seems that this technique uses a search filter but neither in this case I can't reveice changes notifications only for the users from a specific OU. So , I was thinking to create some custom searching filters for a specific type of users (for example: disabled user accounts) but even so, I will have to check the provenience of a user at a specific OU. (inefficient, in my opinion)
Now, here comes the real questions:
How can I track changes in A.D only for a certain group of user accounts? And what would you recommend me to use in this case?
[Edit 1]
I know that I can use USNChanged attribute but, wouldn't be that inefficient if I am planning to work with deleted objects and if I am tracking just some certain changes that took place in an OU?
In the resource definition of a practitioner (http://hl7.org/implement/standards/fhir/practitioner.htm), only one address can be set.
These is a problem for managing physicians with a national identifier (RPPS in France). A physician can have several addresses, they can work in a public hospital and a private organization in the same time, for instance. Some physicians have more than 10 active addresses.
How to deal with that ?
Thanks in advance.
If you only want to have a single resource, you can also use extensions to send additional address repetitions (or any other element you need or don't have enough repetitions for in the core resource). The premise for only allowing 1 reptition in the "core" resource is that the majority of systems will only support one, so we didn't want to try forcing multiple repetitions. But with extensions, you're in no way limited to the cardinality indicated.
In the near future (though probably after the publication of the first DSTU), we'll probably go through all the resources and identify elements with maxOccurs=1 where it would theoretically be possible to have more than one and define standard extensions for sending extra repetitions (just so everyone who encounters this common use-case has a standard extension to rely on)
It is perfectly alright to have more than one Practitioner instance for every role an individual physician can perform. So, you get one Practitioner instance for the professional working in his role within a public hospital, one for that same person working in a private organization etcetera.
For each instance you can give the practitioner qualifications for that specific role, specify a period the professional is allowed to be in that role, give telecom details specific to that role etcetera.
See also the last paragraph in the Practitioner resource
Practitioner performs different roles within the same or even different organizations. Depending on jurisdiction and custom, it may be necessary to maintain a specific Practitioner Resource for each such role or have a single Practitioner with multiple roles. The role can be limited to a specific period, after which authorization for this role ends. Note that the represented organization need not necessarily be the (direct) employer of a Practitioner.
It looks like the value for address is an array with address object/s inside of it meaning you should be able to add as many address objects as you want in the value.
"address" : [{ Address }], // Address(es) of the practitioner that are not role specific (typically hom
This is more of an architectural question. Let's assume we have different types of users logging into a system, and we have a 'customer' entity. Depending on the permissions of the user, I may want to return different sub-sets of 'customer' properties. I also might want to allow edits to only certain properties.
Any suggestions on what path to go down? Here are the options I've thought of thusfar:
For each permission level, extend the model - and return the furthest descendant based upon the user permissions. On the input side, accept the furthest descendant and only cast it to the correct descendant. (Seems like a lot of implicit logic - doesn't seem very elegant)
Create different methods (cluttered API, implies more functionality than I might want to expose)
Any other suggestions?
Thanks
What you're describing is a clear-cut use case for XACML. XACML is the eXtensible Access Control Markup Language. It lets you define fine-grained access control using attributes (about the user, the resource, the environment...).
It's policy-based which means you can write things like:
users can view customer records that are in the same region as the user
users can edit customer records they are directly assigned to
auditors can view customer records for the entire business unit except for sensitive fields
There are several XACML engines out there (WSO2, Heras AF for Java; Axiomatics for .NET).
I've developed quite a few ASP .NET web apps in the .NET 4.0 framework and managed to apply authorization at the presentation tier, the WCF tier, and the data tier. Feel free to ping me for additional information.