public virtual AclExpansionEntry CreateAclExpansionEntry(UserRoleAclAceCombination userRoleAclAce)
{
var accessTypesResult = GetAccessTypes(userRoleAclAce);
AclExpansionEntry aclExpansionEntry = null;
// Create an AclExpansionEntry, if the current probe ACE contributed to the result and returned allowed access types.
if (accessTypesResult.AccessTypeStatistics.IsInAccessTypesContributingAces(userRoleAclAce.Ace) && accessTypesResult.AccessInformation.AllowedAccessTypes.Length > 0)
{
aclExpansionEntry = new AclExpansionEntry(userRoleAclAce.User, userRoleAclAce.Role, userRoleAclAce.Acl, accessTypesResult.AclProbe.AccessConditions,
accessTypesResult.AccessInformation.AllowedAccessTypes, accessTypesResult.AccessInformation.DeniedAccessTypes);
}
return(aclExpansionEntry);
}
public virtual AclExpansionEntryCreator_GetAccessTypesResult GetAccessTypes(UserRoleAclAceCombination userRoleAclAce)
{
if (ClientTransaction.Current == null)
{
throw new InvalidOperationException("No ClientTransaction has been associated with the current thread.");
}
var aclProbe = AclProbe.CreateAclProbe(userRoleAclAce.User, userRoleAclAce.Role, userRoleAclAce.Ace);
// Note: The aclProbe created above will NOT always match the ACE it was designed to probe; the reason for this
// is that its SecurityToken created by the AclProbe is only designed to match the non-decideable access conditions
// (e.g. abstract role, owning tenant, owning group, etc) of the ACE. If this were not the case, then the AclProbe would need
// to reproduce code from the SecurityManager, to be able to decide beforehand, whether decideable access condtions
// (e.g. specific tenant, specific user) will match or not.
//
// The "non-decideable" here refers to the information context of the AclExpander, which is lacking some information
// available during normal SecurityManager access rights querying.
// For decideable access conditons (e.g. specific tenant or specific group), the created SecurityToken
// is not guaranteed to match, therefore the AccessTypeStatistics returned by Acl.GetAccessTypes are used to filter out these cases.
//
// One could also try to remove these entries by removing all AclExpansionEntry|s which are identical to another AclExpansionEntry,
// apart from having more restrictive AccessConditions; note however that such "double" entries can also come from ACEs which are
// being shadowed by a 2nd, less restrictive ACE.
//
// Note also that it does not suffice to get the access types for the current ACE only, since these rights might be denied
// by another matching ACE in the current ACL (deny rights always win).
var accessTypeStatistics = new AccessTypeStatistics();
var roles = aclProbe.SecurityToken.Principal.Roles;
Assertion.IsTrue(roles.Count == 1);
Assertion.IsTrue(object.ReferenceEquals(roles[0].Position.GetObjectReference(), userRoleAclAce.Role.Position));
Assertion.IsTrue(object.ReferenceEquals(roles[0].Group.GetObjectReference(), userRoleAclAce.Role.Group));
AccessInformation accessInformation = userRoleAclAce.Acl.GetAccessTypes(aclProbe.SecurityToken, accessTypeStatistics);
return(new AclExpansionEntryCreator_GetAccessTypesResult(accessInformation, aclProbe, accessTypeStatistics));
}
