API not working with OIDC

[ghost]

When I try to access MISP over API, with OICD configured I get 403.

• I have tried with fresh auth keys, and even with MISP's own REST client in the web UI

Apache logs this:

{
  "@timestamp.nanos": 319537,
  "file": "[censored]",
  "headers": {
  },
  "host": "worker01-misp_vector",
  "loghost": "worker01-misp_misp",
  "message": "[censored] [censored] - [05/May/2022:08:58:34 +0000] "POST /events/index HTTP/1.1" 403 954 "-" "python-requests/2.27.1"",
  "message_key": null,
  "offset": 449880,
  "partition": 2,
  "severity": "info",
  "source_type": "misp",
  "tag": "apache-access"
}

My request header:

{'Authorization': 'xxx', 'Content-Type': 'application/json', 'Accept': 'application/json'}

Do you have any idea what could course this?

[Benni0]

I had this issue a view times but I haven't had time to analyze the problem. For me the keys have been working, after restarting httpd inside the container using supervisorctl.

[ghost]

@Benni0 I tried with /usr/bin/supervisorctl restart httpd but it didnt work. Then I tried to restart the container, that didn't work neither.

As I can understand from OpenID Connect Documentation Apache will not authenticate the API Key, but only check if Authorization is set in the header, and then forward the request to MISP. So shouldn't my deny logs originate from MISP and not Apache?

[Benni0]

In apaches misp.conf a rewrite map is defined which checks the key against cake: RewriteMap authkeys "prg:/var/www/MISP/app/Console/cake user authkey_valid" apache:apache

If you execute the cake command inside the container you should get '1' as result when you insert your API key. As I remember this worked when I had this problem.

[ghost]

I can get it working with the users personal access key, but the ones manual created in /auth_keys/index doesn't work.

[ondj]

@gso-trifork-security Advanced auth keys are disabled by default. If you want to use them, you have to set SECURITY_ADVANCED_AUTHKEYS to yes. See https://github.com/NUKIB/misp#security

[dygland]

I know this is almost two years old but I'm seeing the same behaviour with an user we're using for monitoring purposes, suddenly the user gets a 403 and our checks fail. One remediation seems to be to log in as the user, upon login the checks are successful. Havent been able to find anything that suggests the underlying reasons for this behavior.