fiware POI: cannot add poi: always unauthorized - fiware

I have two instances:
keyrock
Poi with wilma-proxy
Trying to create a poi in instance, allways the response is 401 Permission denied. But token is correct as said proxy log:
2016-10-14 09:40:30.132 - INFO: IDM-Client - Token in cache, checking timestamp...
2016-10-14 09:40:30.135 - INFO: IDM-Client - Token in cache expired
2016-10-14 09:40:30.136 - INFO: IDM-Client - Checking token with IDM...
2016-10-14 09:40:30.342 - INFO: Root - Access-token OK. Redirecting to app...
Refused to set unsafe header "content-length"
2016-10-14 09:40:30.366 - ERROR: HTTP-Client - Error: 401 Permission denied.
So, i think the problem is the authenticate.html file. The only lines i changed are:
<meta name="fiware_lab-signin-client_id"
content="8dc5826cdaea4729a4f43a01d01cb32e">
<meta name="fiware_lab-signin-host" content="http://myserver.com:8000">
fiware_lab-signin-client_id has the client_id of application POI created in my keyrock instance.
the fiware_lab-signin-host has the server AND port of horizon.
Is that correct? I try with 5000 port (keystone) without results.
Also, I found this in add_poi.php:
$session = get_session();
$user_id = $session['user'];
$add_permission = $session['permissions']['add'];
if(!$add_permission) {
header("HTTP/1.0 401 Unauthorized");
die("Permission denied.");
}
If comment these lines, all proccess seems to be correct until the sql insert. (needs the $session['user'] and other parameters that are null)
I dont understand why these lines are there. also, the function get_session() returns a hardcoded array and not the session (which may not have)
I'm so confused how to use this enabler. Anyone knows how to use?

Have you configured the auth_conf.json file with the root user(s) of the POI-DP? Configuring hard users The POI-DP considers the Keystone as a general identity provider (as Google+). You have to separately give permissions to the POI-DP users, first configuring the root users with all privileges and then they can call other users using user_management.html . Site Administration
Please, use the tag fiware-poi for quicker response to POI-DP questions.

Related

CRITICAL keystonemiddleware.auth_token [-] Unable to validate token: Failed to fetch token data from identity server

I am building openstack (Yoga version on Ubuntu 22.04) high availability using ssl configuration. I was able to get other services to work using https (except neutron, cinder and dashboard), but Nova throws the error in /var/log/nova/nova-api.log below:
CRITICAL keystonemiddleware.auth_token [-] Unable to validate token: Failed to fetch token data from identity server: keystonemiddleware.auth_token._exceptions.ServiceError: Failed to fetch token data from identity server
When I run the command below to get token for user "nova" I am able to get a token:
openstack --os-auth-url https://controller:5000/v3 --os-project-domain-name Default --os-user-domain-name Default --os-project-name service --os-username nova --os-password token issue
Controller is the virtual hostname for all controllers (x3). I have all nodes (controller and Compute nodes) configured in /etc/hosts file.
My configuration is as follows:
admin-openrc
export OS_USER_DOMAIN_NAME=default
export OS_PROJECT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=<admin-password>
export OS_AUTH_URL=https://controller:5000/v3
#export OS_SERVICE_TOKEN=
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2
/etc/nova/nova.conf
[keystone_authtoken]
www_authenticate_uri = https://controller:5000
auth_url = https://controller:5000
memcached_servers = 192.168.120.11:11211,192.168.120.12:11211,192.168.120.13:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = nova
password = <nova-passwd>
Your assistance is highly appreciated. Please let me know if you require more info.
Thank you
Thank you for your assistance in advance. I discovered that when I use the config below, everything works fine
frontend glance-api-front
bind 192.168.100.10:9292
default_backend glance-api-back
backend glance-api-back
balance source
option tcpka
option httpchk
# option tcplog
server controller1 192.168.100.11:9292 check inter 2000 rise 2 fall 5
server controller2 192.168.100.12:9292 check backup inter 2000 rise 2 fall 5
server controller3 192.168.100.13:9292 check backup inter 2000 rise 2 fall 5
but when I try to simulate failure of active controller node, I get the error below:
"An unexpected error prevented the server from fulfilling your request. (HTTP 500) (Request-ID: req-8d4979ac-c0f0-4900-94b8-814b855c5853)"
not sure how to configure HA to failover to backup controller nodes
Thank you

IBM MQ doesn't run as mqm on Openshift 4

Hi guys.
I've an IBM MQ image deployed on Openshift 4 and for some reason, the processes don't use the user mqm but the one randomly generated by Openshift itself.
As a result, I've a Java application that tries to connect to the queues and it fails because the authentication fails since it uses mqm as user.
The same exact image running on Openshift 3 behaves as expected. For more details:
Custom image:
FROM ibmcom/mq
ENV HOME /root
COPY config.mqsc /etc/mqm/
and, in the config.mqsc:
DEFINE CHANNEL(PASSWORD.SVRCONN) CHLTYPE(SVRCONN)
SET CHLAUTH(PASSWORD.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody') DESCR('Allow privileged users on this channel')
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('BackStop rule')
SET CHLAUTH(PASSWORD.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) CHCKCLNT(REQUIRED)
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) ADOPTCTX(YES)
REFRESH SECURITY TYPE(CONNAUTH)
DEFINE QLOCAL(MYQUEUE.IN ) DEFPSIST(YES) MAXDEPTH(500000)
DEFINE QLOCAL(MYQUEUE.OUT ) DEFPSIST(YES) MAXDEPTH(500000)
DEFINE QLOCAL(CS.ERROR) DEFPSIST(YES) MAXDEPTH(500000)
ALTER QMGR CHLAUTH(DISABLED) CONNAUTH(' ')
ALTER CHANNEL('SYSTEM.DEF.SVRCONN') CHLTYPE(SVRCONN) MCAUSER('mqm')
REFRESH SECURITY TYPE(CONNAUTH)
The process running on Openshift 4 looks like
1000790+ 232 0.0 0.1 2308688 45776 ? Ssl 09:39 0:00 /opt/mqm/bin/amqzxma0 -m QM1 -x -u 1000790000
but in the Openshift 3 it looks like
1000100+ 152 0.0 0.0 2324200 33812 ? Ssl May03 0:06 /opt/mqm/bin/amqzxma0 -m QM1 -x -u mqm
Another difference are the "capabilties" and the security attributes that the MQ container has on startup.
On Openshift 3:
Capabilities (bounding set): chown,dac_override,fowner,fsetid,setpcap,net_bind_service,net_raw,sys_chroot,audit_write,setfcap
Process security attributes: system_u:system_r:container_t:s0:c0,c15
On Openshift 4:
Capabilities (bounding set): chown,dac_override,fowner,fsetid,setpcap,net_bind_service,net_raw,sys_chroot
Process security attributes: system_u:system_r:container_t:s0:c17,c28
Stacktrace produced by the application:
Caused by: org.springframework.jms.JmsSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'QM1' with connection mode 'Client' and host name 'my-mq(1414)'.; nested exception is com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'QM1' with connection mode 'Client' and host name 'my-mq(1414)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
at org.springframework.jms.support.JmsUtils.convertJmsAccessException(JmsUtils.java:286)
at org.springframework.jms.support.JmsAccessor.convertJmsAccessException(JmsAccessor.java:185)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:507)
at org.springframework.jms.core.JmsTemplate.browseSelected(JmsTemplate.java:1029)
at org.springframework.jms.core.JmsTemplate.browse(JmsTemplate.java:991)
... 78 more
Caused by: com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'QM1' with connection mode 'Client' and host name 'my-mq(1414)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.
at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:531)
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:215)
at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:424)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createV7ProviderConnection(WMQConnectionFactory.java:8475)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createProviderConnection(WMQConnectionFactory.java:7815)
at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl._createConnection(JmsConnectionFactoryImpl.java:303)
at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createConnection(JmsConnectionFactoryImpl.java:236)
at com.ibm.mq.jms.MQConnectionFactory.createCommonConnection(MQConnectionFactory.java:6016)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:111)
at com.ibm.mq.jms.MQQueueConnectionFactory.createConnection(MQQueueConnectionFactory.java:187)
at org.springframework.jms.support.JmsAccessor.createConnection(JmsAccessor.java:196)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:494)
... 80 more
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:203)
... 90 more
Any idea on what the issue could be?
To ensure compliance with security constraints required in a multi-tenant containerized environment, the IBM MQ certified containers, do not support the use of IDs that are defined on the operating system libraries inside a container. There is no mqm user ID or group defined in the container.
For more details read User authentication and authorization for IBM MQ in containers

Fiware AuthZForce error: "AZF domain not created for application"

I'm trying to protect Orion Context Broker using KeyRock idm, Wilma PEP-Proxy and AuthZForce PDP over Docker. For now, level 1 security works well and I can deny access to non logged users, but I get this error on Wilma when trying to add level 2.
AZF domain not created for application <applicationID>
Here it is my azf configuration in Wilma's config.js file:
config.azf = {
enabled: true,
protocol: 'http',
host: 'azfcontainer',
port: 8080,
custom_policy: undefined
};
And this is how I set the access control configuration on KeyRock:
# ACCESS CONTROL GE
ACCESS_CONTROL_URL = 'http://azfcontainer:8080'
ACCESS_CONTROL_MAGIC_KEY = None
I have created the custom policies on Keyrock, but AuthZForce logs don't show any request from KeyRock or Wilma, so no domain is created on the PDP. I have checked that all containers can see and reach each other and that all ports are up. I may be missing some configuration.
These are the versions I'm using:
keyrock=5.4.1
wilma=5.4
autzforce=6.0.0/5.4.1
This question is the same that “AZF domain not created for application” AuthZforce, but my problem persists even with the shown AuthZForce GE Configuration.
I found the cause of this problem that is present when the AuthZForce is not behind a PEP Proxy and therefore the variable ACCESS_CONTROL_MAGIC_KEY is not modified (None by default).
It seems horizon reads both ACCESS_CONTROL_URL and ACCESS_CONTROL_MAGIC_KEY parameters in openstack_dashboard/local/local_settings.py when it needs to connect to AuthZForce. Theoretically, the second parameter is optional (it introduces a 'X-Auth-Token' header for the PEP Proxy), but if horizon detects it is None (the default value in local_settings.py) or an empty string, the log shows a Warning and returns inmediatly from the function "policyset_update" in openstack_dashboard/fiware_api/access_control_ge.py. So the communication to AuthZForce never takes place.
The easier way to solve the problem is to write some text as magic key in: openstack_dashboard/local/local_settings.py:
# ACCESS CONTROL GE
ACCESS_CONTROL_URL = 'http://authzforce_url:port'
ACCESS_CONTROL_MAGIC_KEY = '1234567890' # DO NOT LEAVE None OR EMPTY
Thus, a 'X-Auth-Token' header will be generated, but it shouldn't affect to the communication when the AuthZForce isn't behind a PEP Proxy (the header is simply ignored).
Notice: Remember to delete the cached bytecode file "openstack_dashboard/local/local_settings.pyc" when making changes to assure the new config is updated after restart horizon service.
PS: I sent a pull request to https://github.com/ging/horizon with a simple modification that fixes the problem.

502 (BAD GATEWAY) and 504 (GATEWAY TIMEOUT) in Wirecloud

Time ago we set up a PEP proxy to secure the API our widgets are using. All have being working correctly until today, that we are receiving a 502 Bad Gateway error code for every call going through the proxy.
We have checked the requests are reaching our server and it is responsing correctly to them. The parameters added by the proxy (x-nick-name, x-display-name...) are defined correctly too.
We have also checked the requests outside wirecloud and all go well: we get the token properly and use it in the subsequent calls without problem.
We do not know where this error comes from, any ideas?
EDIT 06/11/2015
After Alvaro's new setting we are receiving the following error in the response body:
{
"description": "Connection Error",
"details": "('Connection aborted.', error(104, 'Connection reset by peer'))"
}
EDIT 09/11/15
Today, the code received in the request's response is different: 504 GATEWAY TIMEOUT
{
"description": "Connection Error",
"details": "('Connection aborted.', error(104, 'Connection reset by peer'))"
}
EDIT 16/11/15
Answering to Mr. Alonso's question:
1.- If we request directly to the server, the response is correctly displayed in the application.
2.- Here you can see the logs from the PEP Proxy with the new line added. As you can see the request is redirected correctly but the info is not displayed in the app.
Seems that the problem is in the PEP proxy side.
I've checked using other tools like curl (I obtained the connection details from the server log). Making the same request using curl gives the same result than using WireCloud: connection reset by peer. Also, if I make the request without the X-Auth-Token header, your service responds with an 401 error code. This is important, because it means that there is not a communication problem between the Mashup portal and your server. I don't know why, but the PEP proxy seems to be crashing when making the authenticated request from the Mashup portal (the same command works executing it from my machine).
I suggest you to restart the PEP proxy. If the problem persist, please attach any available info about the crash from the PEP proxy logs.
You can check three things to give us more information:
Try to remove the PEP and send the request directly to your service.
Introduce a new log in PEP to print the headers of the response: line 41 of lib/HTTPClient.js, log.debug("Headers: ", headers);
Try to send a request to the root path (directly to the tomacat or apache)
If not perhaps we can talk in private to check more information

Authentication error in freeradius server

I have installed freeradius server on Ubuntu-14.04, when I try take radtest on server using, radtest -x bob root123 127.0.0.1 1812 testing123
I get following error when I run freeradius -X,
[sql] User bob not found
++[sql] returns notfound >++[expiration] returns noop >++[logintime] returns noop >[pap] WARNING! No "known good" password found for the user. >Authentication may fail because of this. >++[pap] returns noop >ERROR: No authenticate method (Auth-Type) found for the request: >Rejecting the user >Failed to authenticate the user >Using Post-Auth-Type Reject
I have added user in users file, bob Cleartext-Password := "root123"
In eap.conf file, default_eap_type = peap
Still getting an error, can anyone help me to resolve my issue?
Have you enabled the text-file as a valid source for your users?
The error message seems like you just enabled sql but not the
#
# Read the 'users' file
files
in the sites-enabled/default (and innter-tunnel)
Hopefully this fixes your problem