Вы можете использовать ACL для ограничения типа создаваемых или доступных для просмотра участников администраторами Организации.Простейшим способом обозначаются классы участников для каждой организации и контролируется доступ к участникам по классу
. Альтернативно, они могут быть в одном классе участников, но иметь идентифицирующие метаданные организации, т.е.если вы действительно настаиваете, чтобы участники создавались в одном классе участников.Тогда (при наличии ACL) администратор организации из «другой организации» не сможет связать выданную им идентификацию с «неправильным» участником (т. Е. С тем, кого он даже не должен видеть, чтобы связать его), потому чтопроверка состояния в ACL заблокирует доступ.
например,
rule myRule1 {
description: "Org admin can see/access/create participants matching own org"
participant(p): "org.acme.nwk.IssuerAdmins" // ie only someone of this class, can 'issue identities' -
operation: ALL // (CREATE, READ, UPDATE, DELETE) // do everything, for IDs in their Org ?
resource(r): "org.acme.nwk.myParticipants"
condition: (p.organisation == r.organisation) // can ONLY see or do anything with participants from own Org
action: ALLOW
}
Администратор организации из «другой» организации - может выдавать удостоверения, но не сможет видеть участника «не в его / ее организации» (чтобы попытатьсясопоставить с идентичностью своей собственной организации).
Возможно быть более «кратким» и основывать его на данных, но размещение сложных вычислений javascript (проверьте значение атрибута для последовательности шаблонов Org и т. д.) добавляет дополнительные издержки, еслибольшое количество данных сравнивается с.Вы также можете сделать другой способ: