I want to know how the role based authorization works in FIWARE Keyrock. I have tested a scenario where a user A registers an application appA in Keyrock. The user B that is not on the authorized list for application appA can request a token for another application (appB, for example) and successfully access the appA with the token obtained from appB.
Another test performed was to include user A in the authorized list for appA, but with a role that has no permissions. Again, the user A gets access to appA with credentials from another application.
Can anyone explain me how this work, if it really work?
As #Álvaro said in comments, we can see an example of this configuration at this video.
When I saw this video, previously, I had ignored the exact part of permission configuration at Keyrock, because it was not of my interest. Now, I am interested in this functionality and I had forgot that this video presents such information.
Besides, below I put what I had to do for things work:
Install AZF:
sudo apt-get install openjdk-7-jdk (if you dont have)
sudo apt-get install tomcat7
wget http://repo1.maven.org/maven2/org/ow2/authzforce/authzforce-ce-server-dist/5.4.1/authzforce-ce-server-dist-5.4.1.deb (authzforce)
sudo apt-get install gdebi curl
sudo gdebi authzforce-ce-server-dist-5.4.1.deb
Configure Wilma PEP (config.js file):
config.azf = {
enabled: true,
protocol: 'http',
host: '10.30.0.21', //this is your authzforce ip
port: 8080, //6019,
custom_policy: undefined // use undefined to default policy checks (HTTP verb + path).
};
Configure Keyrock (local_settings.py file, located in /horizon/openstack_dashboard/local/local_settings.py)
ACCESS_CONTROL_URL = 'http://10.30.0.21:8080'
ACCESS_CONTROL_MAGIC_KEY = None # If you have problems, put something instead of None. Currently there is a reported bug related to this.
Remember to restart the services. To let the things work, you need to create the specific permission to the right endpoint of the application you want to secure/access. Once it is created, the AZF will be consulted by the Wilma PEP Proxy.
I hope it helps someone.
Related
I'm working on an apache module that can check the libipset API to test if an IP is in a list. This is being used as a backup firewall for proxied connections.
I've managed to get everything working up until the C script calls type = ipset_type_get(session, cmd);. After testing, I believe the main problem is that libipset requires higher permissions. I'm not getting a permission error, just a null value. However, when I run the C script directly using apache as the user, I can get it to work when I grant sudo privileges to apache for the script.
I've tried 1 and 2 in the answers here and they've both failed. Is there any other way to force root for the ipset API call?
This action might need cap_net_admin.
If using systemd to control the process, you can add it like this:
[Service]
...
CapabilityBoundingSet=CAP_NET_ADMIN
Another approach would be to set the binary executable's capabilities.
setcap cap_net_admin=ep /usr/sbin/apache2
If using apparmour, you coould instead set up a profile for apache and include the line
capability net_admin,
in the file ( /etc/apparmor.d/usr.sbin.apache2 )
( see here : https://serverfault.com/questions/932410/enabling-apparmor-for-apache2-in-ubuntu-18-04 )
I am using the below command in jenkins to deploy the api proxies to apigee edge.
apigeetool deployproxy -u abc -o nonprod -e dev -n poc-jenkins1 -p xyz
But am getting the below error.
Error: Path /poc-deployment-automation conflicts with existing deployment path for revision 1 of the APIProxy poc-deploy-automation in organization nonprod, environment dev
Here is my requirement , please help me what command to use.
If API doesn’t exist in target environment, Create Api in new environment with version 1.
If API already exist in target environment, Create Api in new environment with new version (previous version + 1)
So what command should we use to fix the above error and what should we use to do the above 2 tasks.
Help Appreciated.
The apigeetool deployproxy command supports by default your requirements. It deploys the revision 1 if there is no proxy with the name, and increases the revision if it already exists.
However, based on the error you mentioned, it seems that you have a path conflict between two proxies. You are trying to deploy a proxy to a /poc-deployment-automation basepath, but there is another proxy called poc-deploy-automation which is listening on the same basepath. It is not possible, even if the proxy name is different, because the basepath is what apigee uses to redirect traffic to your proxy.
Check the xml file at the root of your proxy and change the basepath attribute.
Also, the basepath of an API Proxy can be anything, but could not be the same used at the same time by two proxies--only one can be deployed at time. The revision numbers are irrelevant in this situation.
Our team decided to try using OpenShift Origin server to deploy services.
We have a separate VM with OpenShift Origin server installed and working fine. I was able to deploy our local docker images and those services are running fine as well - Pods are up and running, get their own IP and I can reach services endpoints from VM.
The issue is I can't get it working, so the services are exposed outside the machine. I read about the routers, which suppose to be the right way of exposing services, but it just won't work, now some details.
Lets say my VM is 10.48.1.1. The Pod with docker container with one of my services is running on IP 172.30.67.15:
~$ oc get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-svc 172.30.67.15 <none> 8182/TCP 4h
The service is simple Spring Boot app with REST endpoint exposed at port 8182.
Whe I call it from VM hosting it, it works just fine:
$ curl -H "Content-Type: application/json" http://172.30.67.15:8182/home
{"valid":true}
Now I wanted to expose it outside, so I created a router:
oc adm router my-svc --ports='8182'
I followed the steps from OpenShift dev doc both from CLI and Console UI. The router gets created fine, but then when I want to check its status, I get this:
$ oc status
In project sample on server https://10.48.3.161:8443
...
Errors:
* route/my-svc is routing traffic to svc/my-svc, but either the administrator has not installed a router or the router is not selecting this route.
I couldn't find anything about this error that could help me solve the issue - does anyone had similar issue? Is there any other (better/proper?) way of exposing service endpoint? I am new to OpenShift so any suggestions would be appirciated.
If anyone interested, I finally found the "solution".
The issue was that there was no "router" service created - I didn't know it has to be created.
Step by step, in order to create this service I followed the instructions from OpenShift doc page which were pretty easy, but I couldn't login using admin account.
I used default admin account
$ oc login -u system:admin
But instead using available certificate, it kept asking me for password, but it shouldn't. What was wrong? My env variables were reset, and I had to set them again
$ export KUBECONFIG="$(pwd)"/openshift.local.config/master/admin.kubeconfig
$ export CURL_CA_BUNDLE="$(pwd)"/openshift.local.config/master/ca.crt
$ sudo chmod +r "$(pwd)"/openshift.local.config/master/admin.kubeconfig
This was one of the first steps described in OpenShift docs OpenShift docs. After that the certificate is set correctly and login works as expected. As an admin I created router service (1st link) and the route started working - no more errors.
So in the end it came out to be pretty simple and dummy, but given that I didn't have experience with OpenShift it was hard for me to find out what is going on. Hope it will help if someone will have the same issue.
I have been trying deal with LDAP for my Kerberos Authentication. I have successfully run Kerberos Authentication for Squid and SquidGuard using LDAP (AD). It's working well aside from the user filter function.
squidGuard.log shows the error:
Added LDAP source: internal%5csquidusertest
I have bump on this articlet: http://gotoanswer.stanford.edu/?q=SquidGuard+-+Ldap+doesnt+filter+users
But the hyperlink is no longer working as when you try going to the the main login page, it won't give the ability to register (page is not loading).
I wonder if someone has the copy of that patch.
Thanks in advance.
As I check the compiled package for Debian Wheezy, I can see that the package for squidguard already includes the patch. It might be something on the configuration of my squidguard file.
I installed cloudfoundry with the -D option to change the default domain. Cloudfoundry installs fine and starts but when I try to vmc in I get an error:
swampfox#swampcf:~$ vmc target api.mydomain.com
Successfully targeted to [http://api.mydomain.com]
swampfox#swampcf:~$ vmc register --email emailid#gmail.com --passwd mypass
Creating New User: OK
Attempting login to [http://api.mydomain.com]
Problem with login to 'http://api.mydomain.com', target refused connection (getaddrinfo: Name or service not known), try again or register for an account.
swampfox#swampcf:~$ vmc register --email emailid#gmail.com --passwd mypass
Creating New User: Error 100: Bad request
Can someone help. I need to have the external uri or this is useless for me.
This works fine if I take the default api.vcap.me but it only works on that vm and is not accessable from other infrastructure which is pretty useless.
I have found the issue. There is a bug in vmc-0.3.21. Backed it down to vmc-0.3.18 and everything works now.
Whoof! How to open a bug against vmc?
When you have tried api.vcap.me, did you do this by just changing the endpoint address in config/cloud_controller.yml? If so, it may be worth checking to see if the setup did set the endpoint correctly in all the other configuration files, uaa.yml especially in this case as you are having issues with login.
I have always used the standard configuration (api.vcap.me) and then manually changed the endpoint in all the configuration files using sed, for example, from the config directory;
sed -i 's/\.vcap\.me/.newdomain.com/g' *.yml
Actually I initially installed with default api.vcap.me. Then i wiped out the guest an completely reinstalled with -D mydomain.com. I have subsquently installed another CF on a different guest with api.vcap.me for comparison.
Checked the config /home/cfadmin/cloudfoundry/.deployments/devbox/config/uaa.yml and there is no reverence to api.swampnet.com or api.vcap.me.
Just a quick note. I can successfully login from an external domain like emc.com but i cannot login on the local machine or a machine in the same subnet. Whoof!
I noticed that the controller had external uris false so I set them to ture but that made no difference. If I set them to true on the api.vcap.me instance will that allow me to push and app with an external uri?