I've deployed an application based on Fiware generic enablers, in Docker. The versions are:
Orion 1.14
Cygnus 1.9.0
Authzforce 5.4.1
Keyrock: the latest
Pep-proxy: 7.0.1
but, when I want to create a permission in keyrock I can't find a specific syntax or character sequence to enter a dynamic resource in the resource field like: /resource1/<user>/info, or to specify only the resource prefix like: /resource2/<whatever>.
Really exists the syntax for the dynamic resource and authzforce can create a permissions asociated to a dynamic resource or is necessary create a XACML rule?
Yes, it is necessary to create an Advanced XACML Rule. For example, you may look at the XACML Rule template in the IDM source code, which is used to generate a basic Rule (for a static resource path); you would have to customize it (besides removing the template code <%...%>), especially modify the Target and the Condition elements (use XACML function string-concatenate to create the string /resource1/{param}/info dynamically).
Another difficulty is to get the {param} value in the PEP, and make sure it is sent in the XACML Request to AuthzForce PDP. The Pep-proxy only gets/sends the following XACML attributes as you can see from the Pep's Authzforce client code (names shortened for conciseness): resource-id, sub-resource-id, action-id, subject-role. Therefore, if you want the user-id as {param} for example, you have to modify the Pep code I just mentioned, i.e. extract the user ID from the userInfo variable and add the corresponding XACML Attribute (subject-id) in the Request. Or use your own Pep and do whatever you want of course.
Related
After testing authentication in Orion with keycloak (Orion APIs authentication through Keycloak) with kong-pep-plugin, I'm interested in the authorization too; in particular, I want to give specific permissions (on path and verb) to users/groups like I used to do with AuthZForce.
Could you help me?
Thank you
sorry that I only see your request right now. This is very much tied to configuring Keycloak, but it is possible, yes. The kong-pep-plugin delegates all decisions to Keycloak's Authorization Serivces and just takes its decision. Thus, you should read the documentation on that: https://www.keycloak.org/docs/latest/authorization_services/index.html
An example (declarative)configuration for allowing different groups to access different paths can be found in the integration-tests:
https://github.com/FIWARE/kong-plugins-fiware/blob/main/it/src/test/k3s/keycloak.yaml#L518-L567
Another, better readable, example is our demo environment:
https://github.com/FIWARE-Ops/fiware-gitops/blob/master/aws/fiware/keycloak/templates/realmConfigMap.yaml#L139-L203
This combination of resources and policies allows the group "consumer" to access the path "/keycloak/ngsi-ld/v1/", while the group "admin" can also access "/keycloak/".
The authorization services allow for much more fine-grained and powerful configurations, so I really recommend the official documentation on it.
Best
As an addition for the GET/POST question:
Thats something you can implement with the javascript policies feature from Keycloak(keycloak.org/docs/latest/authorization_services/…). The kong-plugin forwards the http method as "http.method" claim(see github.com/FIWARE/kong-plugins-fiware/blob/main/kong-pep-plugin/…)
An example policy could granting access only for GET requests could look like:
var context = $evaluation.getContext();
var attributes = context.getAttributes();
var method = attributes.getValue('http.method').asString(0);
if (method === 'GET')
{$evaluation.grant();
Combining a resource policy with such a js-policy would give you the access-control you want.
I want to configure Apereo CAS 6.0.x to perform X.509 authentication and then retrieve principal attributes from a database table.
Rudimentary X.509 authentication is working with these lines in application.properties (and appropriate reverse proxy setup):
cas.authn.x509.extractCert=true
cas.authn.x509.sslHeaderName=SSL_CLIENT_CERT
cas.authn.x509.principalDescriptor=SUBJECT_DN
The default "Log In Successful" page shows that it knows how to get my certificate's subject DN.
But I can't figure out how to tell CAS to then use that subject DN value to query my database for additional attributes.
This page explicitly mentions my need (though with LDAP instead of JDBC), but does not say specifically how to achieve it:
In many cases it is necessary to perform authentication by one means and resolve principals by another. The PrincipalResolver component provides this functionality. A common use case for this this mix-and-match strategy arises with X.509 authentication. It is common to store certificates in an LDAP directory and query the directory to resolve the principal ID and attributes from directory attributes. The X509CertificateAuthenticationHandler may be be combined with an LDAP-based principal resolver to accommodate this case.
What properties need to be set so that the X509 authentication handler resolves the principal against the database?
The missing ingredient was this line in application.properties:
cas.authn.x509.principalType=SUBJECT_DN
Without it, CAS does not attempt to query any attributeRepository settings that you may have.
I would like to know if is possible achieve this work environment:
I'm building a secure Orion Context Broker through PEP, PDP, PAP, etc.
I would like that, in case of Orion stores an abnormal value for an attribute, an alert was sent (an email, e.g) and, a new XACML rule was created so a role-user can see those values (before this happens he doesn't have to have permission to see it).
Is it possible? If it is, how can I achieve it?
Is there any option to do it through jenkins?
in case of Orion stores an abnormal value for an attribute, an alert was sent ( e.g an email)
The FIWARE component to use to send an eMail in this case would be Complex Event Processing - e.g. Perseo
You can set up an EPL rule to send an eMail
Set up an XACML rule to only allow access if an attribute is "abnormal"
This looks like a standard <Condition> clause, for example, the following:
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equal">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">
<EnvironmentAttributeSelector DataType="http://www.w3.org/2001/XMLSchema#time"
AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"/>
</Apply>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">17:00:00</AttributeValue>
</Apply>
</Condition>
will only allow an action after a certain time of day.
I guess you may be looking at using "urn:oasis:names:tc:xacml:1.0:function:double-greater-than" or urn:oasis:names:tc:xacml:1.0:function:integer-greater-than" in the <Condition> something like:
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-greater-than-or-equal">
<SubjectAttributeDesignator SubjectCategory="urn:oasis:names:tc:xacml:1.0:subjectcategory:accesssubject" AttributeId="SubjectClassificationRank" DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="false"></SubjectAttributeDesignator>
<ResourceAttributeDesignator AttributeId="ResourceClassificationRank" DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="false"></ResourceAttributeDesignator>
</Apply>
Now here is the tricky bit, you will need to amend the code of your PEP proxy to ensure you can pass the the value of the "abnormal" attribute so that Authzforce can adjudicate.
The logic will need to be something like this:
Whenever the PEP Proxy is invoked, within the PEP Proxy make a direct call to Orion to retrieve the current attribute value.
Within your PEP Proxy amend the XML creation function to add the relevant attribute.
Call Authzforce to check if the request is permitted
The point here is that the standard code of the PEP Proxy won't have the necessary information to allow Authzforce to adjudicate, so you're going to have to add in more information.
A simpler scenario of the same type occurs within the following Tutorial - here the User's eMail address is added to the request to Authzforce, you'll just have to apply the same principle.
I have connected Wso2 with an external LDAP. So, i want to handle the LDAP groups. However in Wso2 doc it states to use :
groupOfNames as our objectClass and
member as our MembershipAttribute
However my current LDAP server is not like that. This means that i use
PosixGroup as my objectClass and
memberUid for my MembershipAttribute
This leads me to the point that , when i add a user to a group, then Wso2 goes and puts this value uid=b1,ou=users,dc=transip,dc=nl inside memberUid. This is not compatible with my set up. What i need is Wso2 to just put the user's uid in the memberUid field and then the entry will be compatible with the rest of my setup.
How can i configure Wso2 to pass the uid when adding a user to a group instead of passing dn (Distinguished Name).
According to JIRA [1], this issue has been already fixed in WSO2 IS 5.1.0. According to the JIRA to get your setup working you need to configure GroupObjectClass as "PosixGroup" and MembershipAttribute as "memberUid" in the UserStoreManager configuration relevant to your UserStore.
[1] https://wso2.org/jira/browse/IDENTITY-3400
The same question has posted in https://wso2.org/jira/browse/IDENTITY-6295 as well. In order to achieve this its need to write custom user store manager, changing member attribute to add only uid, rather full DN.
I want to add additional validation to allow the login, ie, not just check that the username and password match but do other validations on the user before allowing him to login.
I tried extending JWTTokenAuthenticator but it seems none of its methods are called during the login.
I thought of using a custom "AuthenticationSuccessHandler" but I'm not sure if this is the place I should do this and how could I report from there that the "login" is actually invalid.
Where should I put this logic?
I end up replacing the "login_form" authentication shown on the LexikJWTAuthenticationBundle bundle documentation for a custom guard authentication just for the login, i.e. different than the guard authentication used to validate the JWT tokens.
In the past, I had a similar requirement. Within the alternatives I chose to implement a custom user provider. Symfony documentation on custom user provider creation is more than enough to accomplish the task. Moreover, "Configuring the user provider" section of the LexikJwt documentation explains how to configure lexik_jwt accordingly.