When it comes to Windows permissions a security principal (Admin1) can gather information on another security principal (User1) e.g. their (SID) and group membership (Group SIDS). Then take this list of SIDS and compare it to an ACL (for example on a file/folder) to check if this other security principal (User1) has rights to a given resource
there is some basic information at the this link
The thing I do not quite understand at the moment is 'under what identity' does Admin1 request User1 SID and User1 Group SIDs
for example in the above link the MSDN talks about Kerberos, and my understanding of Kerberos is the TGT or ST is encrypted using the hash of the security principals (SPN) password e.g. either the password has for krbtgt for TGTs and the password has for the SPN for a given SPN (like a CIFS service).
I understand the service/session (in 'Service for User to Self') requests a Kerberos service ticket ST for 'itself' and therefore the service is able to decrypt the ST to extract the SIDs
However what gives the Service/session the 'right' to ask for SIDs for another user?
is it simply because any security principal authentication to AD can 'read' attributes of another security principal and therefore request this list? I assume so
I am not a programmer, but rather a Micrsoft Server/System engineer
Related
We have ActiveMQ Artemis 2.26.0 which is configured for Active Directory domain authentication.
When a user is authenticated the role is assigned using group membership (userRoleName="memberOf") or username (userRoleName="sAMAccountName"). Is it possible to grant authorizations using both username and groups to which user belongs to?
Currently I have a login.config which works differently for users in different organizational units of domain:
LDAPLogin {
org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule sufficient
debug=true
initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
ignorePartialResultException=true
connectionURL="ldaps://domain-controller1:636 ldaps://domain-controller2:636"
connectionUsername="bind_username"
connectionPassword="bind_password"
connectionProtocol="s"
connectionTimeout="5000"
readTimeout="5000"
authentication=simple
userBase="OU=OU_for_application_users,DC=company,DC=tld"
userSearchMatching="(sAMAccountName={0})"
userSearchSubtree=true
userRoleName="sAMAccountName"
;
org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule sufficient
debug=true
initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
ignorePartialResultException=true
connectionURL="ldaps://domain-controller1:636 ldaps://domain-controller2:636"
connectionUsername="bind_username"
connectionPassword="bind_password"
connectionProtocol="s"
connectionTimeout="5000"
readTimeout="5000"
authentication=simple
userBase="OU=OU_for_team_users,DC=company,DC=tld"
userSearchMatching="(sAMAccountName={0})"
userSearchSubtree=true
userRoleName="memberOf"
roleName="CN"
;
};
User from OU_for_application_users gets one role which is equal to username, and user from OU_for_team_users gets roles from list of groups to which the user belongs to. Technically it is different types of users (special application accounts and personal user accounts).
Is it possible to create a login.config which assigns to user a list of roles which combine username and list of user groups? Or is there any other way to add authorizations which use both username and group of user?
Also I think if it is a good idea. In other brokers, for example IBM MQ, we can configure separate authorizations for users and for groups. In ActiveMQ Artemis we have only one "role" regardless of what it represents - username or group name.
ActiveMQ Artemis supports roles based access control. There is no option to configure authorization based on username.
The configuration of the LDAPLoginModule is limited to userRoleName when assigning roles. However, JAAS login modules are pluggable so you are free to write your own or contribute changes to LDAPLoginModule to support the behavior you want.
RFC 7519 (https://datatracker.ietf.org/doc/html/rfc7519)
mentions a principal but doesn't define it.
What is a JWT Principal?
From Wikipedia:
A principal in computer security is an entity that can be authenticated by a computer system or network.
Let's consider an example where we're using JWT for user's authentication, then e.g. in the Subject Claim's definition from the RFC 7519:
The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
, principal is a specific user for whom a specific token was issued, and "sub" claim is some id of this user.
I'm having trouble understanding the logic when evaluating permission for a shared resource.
Alice creates the resource aliceResource with the scopes read, create, delete
Alice creates the policy isAdmin that verifies if a user is admin
Alice creates a permission that applies the policy isAdmin to the resource aliceResource
Alice shares the resource aliceResource with the scope read to the user Bob
Evaluating permissions
For aliceResource in the scope read for bob with no role assigned.
Question 1. Why is it ignoring the policy isAdmin that is applied to the resource ?
For aliceResource in the scope delete for bob
Question 2. When bob has no role assigned, why the policy resource owner is granting read even though I'm evaluating for the scope delete ?
Question 3. When bob has the role admin, why is it the result permit ?, Alice shared the resource with bob for read not delete
I would appreciate if someone could help me understand what's going on.
Thanks
Edit 1.
I have my client evaluation strategy set to unanimous, what I would expect is for all the policies to apply but if I evaluate for a user that has role admin with whom the resource has not been shared, the decision is grant, how can I make the client enforce all the policies ?
Right now the client is doing an or between my policies and the policies created by keycloak when the resource is shared.
Keycloak did not crystal clear documentation for grant decisions.
This diagram is my understanding. The key is Client Decision Strategy
if set Affirmative, will OR logic.
if set Unanimous, will AND logic.
I made my own permissions(read, delete, and create) and policies. Each permission has a single scope (read, delete, or create). Bob assigned read policy, admin assigned all three policies. The permission decision strategy does not affect in this case (due to single assigned between permission and scope)
If set it with Disabled, any users can access the aliceResource.
This affects two cases by set client decision strategy. for bob
This affects two cases by set client decision strategy. for admin
So, if you want to allow bob only read scope and admin three scopes, the client decision should be Affirmative
This is my test decision results.
Can you please explain how can i setup the role management and security groups in suiteCRM to achieve this,
Two General Manager, they cannot access the records of other GMs and his team records
Any number of Divisional Managers under GM, they cannot access the records of their own GM, other GMs, and other DM but can access the reports of SR under them.
SR (Sales representative) can access only their own records.
Thanks :)
Try this (not tested)
Create All Security groups for DM. This is the main unit of security.
Assign the GM users to the DM security groups they have access to. No need to create a GM group, just give them access to the groups they need.
Create SR role and set the permissions to own. Assign SR users to this role. This will restrict users in this role to only see their own records.
Create DM role and set the permission to group. Assign DM users to this role. Only one DM role is needed, and ALL of the GM and DM users should belong to it.
Add SR and DM role to all the DM security groups.
The logic is like this
Users who try to access a record will have to go through their Roles First, if its say Own, then that's where the security logic compares the owner of the record.
If the users Roles have a Group setting then User groups will be scanned, and check if the record belongs to someone on those groups. If not access is denied.
So thats it, the Group setting needs to be on each module you want to restrict access to, sadly this is a manual work. Take a look at this image, you can see the different types of access you can grant on a role/action.
I'm working on implementing a web service that uses X509 certificates for authentication and authorization of the caller.
Is it proper to specify the entity type (i.e. "end user" or "device") as part of the subject name, with, say, OU RDN?
Is it proper to specify the identity of the entity as part of the subject name, with CN RDN?
Is the best place for the authorization tokens to be part of the X509.v3 extensions (I understand authorization info, like "have access to cookie jar", doesn't belong in subject name section)?
If I am to include custom extension values into the certificates, is the proper way to do so is to apply for an OID (through PEN), and create child OID(s) that designate authorization information, and use these OID(s) as OIDs for the extensions? If that's wrong for some reason, any pointers to how this should be done in a standard way, would be appreciated.
It is proper to specify the entity's identity in the Common Name (CN) field of the Subject Distinguished Name (DN).
For a user or device, it would be appropriate to also specify the Organization (O) and/or Organizational Unit (OU) to which they belong in the Subject DN. There is also the User ID (UID) component.
There is a standard profile of X.509 for authorization assertions specified in RFC 5755. An attribute certificate bears one or more attributes about an identity such at group membership, role, clearance level, etc, as well as referencing the public key certificate (that is, the usual kind of X.509 certificate) of the identity to which the authorization information applies.
This standardized approach avoids any need to devise custom X.509 extensions, and hence, apply for an official OID (which is just as well, because I don't know the "offical" procedure for this.)