I'm trying to protect a web application with OpenAM Policy Agent 3.3.0 on an Apache web server.
The application uses the following URL-styles:
http://my.host.name/appname/some/static/contents
http://my.host.name/appname/some?dynamic=content
http://my.host.name/appname/?interesting_query;with_data
I can successfully handle the first two with the following match patterns
http://my.host.name/appname/*
http://my.host.name/appname/*?*
but I'm failing to find a pattern that matches the last URL-style.
I already tried:
http://my.host.name/appname/?*
http://my.host.name/appname*?*
The OpenAM docs give me no clue how to handle this type.
What would be the correct matching pattern for this URL?
There is a known bug (https://bugster.forgerock.org/jira/browse/OPENAM-3667) in the agents, which means that if you have a "/?" in your URLs, you will be unable to evaluate policies against those resources, they will always result in a deny. This issue was tackled in the end on both the agent and AM side, so you will most likely would need to upgrade to Agents-3.3.1 and 11.0.1 releases (both of them are only available to subscription customers).
Related
We use Application Insights on Frontend and we also use Azure Front Door with WAF(Web Application Firewall) policy.
I can see in WAF logs that a lot of requests are blocked by some WAF Managed Rules.
When I have inspected the WAF logs I found out that requests are blocked by value in cookies ai_session and ai_user (App insights cookies).
Rules that blocks requests:
(942210) Detects chained SQL injection attempts 1/2 - block request because of OR value in ai_session cookie like this:
D/6NkwBRWBcMc4OR7+EFPs|1647504934370|1647505171554
(942450) SQL Hex Encoding Identified - block because of Ox value in ai_user cookie like this:
mP4urlq9PZ9K0xc19D0SbK|2022-03-17T10:53:02.452Z
(932150) Remote Command Execution: Direct Unix Command Execution - block because of ai_session cookie with value: KkNDKlGfvxZWqiwU945/Cc|1647963061962|1647963061962
Is there a way how to force App Insights to generate "secure" cookies?
Why does Azure generate cookie values that on the other side cause blocking requests by Azure Firewall?
I know that I can allow those WAF Rules but is there any other solution?
We have started to encounter this error as well; disabling (or setting to allowed) the OWASP rules as you indicated will work.
I have opened a bug report on the project page that outlines this in more detail here: https://github.com/microsoft/ApplicationInsights-JS/issues/1974 the jist of it, as you identified is the WAF rule's Regex being overzealous.
The IDs that are eventually used by the cookies are generated by this section of code:https://github.com/microsoft/ApplicationInsights-JS/blob/0c76d710a0cd465f0b8b5e143250898122511874/shared/AppInsightsCore/src/JavaScriptSDK/RandomHelper.ts#L125-L145
If the developers chose, they have various way to solve the problem:
Test the generated cookies against the list of known regex and then regenerate on failure.
Remove some of the offending combinations to avoid the rules entirely.
We'll have to see how that plays out. If you cannot do this, in theory you could branch the project and then add such changes yourself but I would not recommend vendoring the SDK.
I have a Trino cluster configured to use LDAP and I want to use Superset to connect to it.
The Trino cluster uses HTTPS with a self signed certificate
I managed to configure Superset to use LDAP, that's not the problem.
I also managed to query Trino by having the following configuration:
sqlalchemy URI: trino://myuser:mypassword#trino_server:8443,
security extra config: {"connect_args": {"verify": false}}
Now here's the problem: Under the security tab there's a checkbox that says "Impersonate logged in user (Presto, Trino, Hive and GSheets)"
. I checked the box, and still the queries I execute run with the user "myuser" which is configured in the sqlalchemy URI, instead of the logged in user.
I'm using Superset version 1.3.2
Does anybody know how to solve this?
There are two components to get user impersonation working with Trino and Superset:
A version of Superset that supports user impersonation with Trino.
This was added officially in 1.3.0, and since you're on 1.3.2 that shouldn't be a problem.
A Trino client that supports user impersonation.
AFAIK the only Python client that currently works with Superset to connect to Trino is sqlalchemy-trino. I couldn't find any specific changes made for user impersonation until 0.4.0, but I have gotten this working with the older 0.3.0 version.
There may be some other possibilities that could prevent user impersonation from working, but less likely:
Make sure that all containers have a working version of sqlalchemy-trino installed. This depends on how you add Python requirements, but I believe I've seen cases where Superset containers don't have the same dependencies, i.e. the superset_app container has the correct module, but not the superset_worker container.
Make sure that the HTTP headers in the requests going to Trino are not being modified. User impersonation works by authenticating with basic authentication but impersonating the user added in a HTTP header called 'X-Trino-User'. If the HTTP header is removed or changed, then the user impersonation won't work as expected.
just wanted to let you know that I managed to solve this issue.
The problem was that I put this configuration - {"connect_args": {"verify": false}} in the "SECURE EXTRA" section under the "Security" tab, instead of in the "ENGINE PARAMETERS" section under the "Other" tab.
Let's start with some context:
I'm studying CKS and reading CIS_Kubernetes_Benchmark_v1.6.0.pdf and there's a confusing section:
1.2.17 Ensure that the admission control plugin NodeRestriction is set (Automated)
...
Verify that the --enable-admission-plugins argument is set to a value that includes
NodeRestriction.
Remediation:
Follow the Kubernetes documentation and configure NodeRestriction plug-in on kubelets.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-
apiserver.yaml on the master node and set the --enable-admission-plugins parameter
to a value that includes NodeRestriction.
The part about check if /etc/kubernetes/manifests/kube-apiserver.yaml has an entry for - --enable-admission-plugins=NodeRestriction,... makes sense, the annoying part is
"Follow the Kubernetes documentation and configure NodeRestriction plug-in on kubelets."
Is extremely hard to google, and the Kubernetes official docs aren't clear about how to do this.
So now that the context is there the question is:
After setting - --enable-admission-plugins=NodeRestriction on the kube-apiserver, how do you verify that the NodeRestriction plug-in on the kubelet has been correctly configured?
To properly enable NodeRestrictions Admission Controller Plugin, you actually need to update kubernetes configuration in 3 different places:
kube-apiserver: - --enable-admission-plugins=NodeRestriction,...
kube-apiserver: - --authorization-mode=Node,RBAC (You must have Node specified)
kubelet (of every node): /var/lib/kubelet/config.yaml should have authorization.mode: Webhook (Other kubernetes distributions may substitute /var/lib/kubelet/config.yaml with another method of configuring it, but I'm sure there'd be a matching value)
When kubelet's authorization.mode is set to Webhook, instead of it's default of AlwaysAllow, it offloads authorization decisions to the kubernetes api-server. The Node Authorization mode is a special-purpose authorization mode that specifically authorizes API requests made by kubelet.
(The giantswarm article below is a great read, and does a good job explaining why you should implement this setting, I'll try to summarize it by saying that's generic hardening that helps prevent privilege escalation by a compromised workload or bad actor.)
Sources:
1.) Kubernetes Security Essentials (LFS260)
2.) Securing the Configuration of Kubernetes Cluster Components
3.) Using Node Authorization
I'm not sure that this is a proper question. (I'm the novice about stackoverflow strategies)
I'm trying to configure SSO systems using OpenAM.
OpenAM... is not a light solution, but I did get my solution for my boss' request.
We have several Web Applications. (App1, App2, App3, ...)
I simulated the combination [OpenAM + App1].
That's OK~ (though much time and so many trials were needed.)
I used domain names following the guide.
[openam.example.com + www.app1.com]
But, in our real circumstances, We should use the IP addresses.
(for example, OpenAM : 1.1.1.1, App1 : 2.2.2.2)
Guide seems to say "it's not possible"...
and I failed about that trial.
when I used 'localhost' or '127.0.0.1' (for simple simulations)
App1(tomcat) failed to start.
Agent's logs were like this...
ERROR: Failed to obtain auth service url from server: null://null:null
ERROR: AdminTokenAction: FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
com.sun.identity.agents.app.username
com.iplanet.am.service.password
Is there a way to user IP addresses for OpenAM SSO?
If possible, my situation is just due to my mistake?
Thank you in advance... (and sorry for my poor English)
In short - no, it is not possible. You must use DNS names (and do not use localhost - this is asking for trouble). OpenAM uses cookies for SSO, and cookies require DNS names.
Are there any guidelines or best practices for handling expired passwords for scenario with active clients via WS-Trust?
For now I have couple of ideas, but can't find any info about it:
1. Issue special token, so client can determine, that is should show change password notification.
2. Throw specific exception.
Maybe I am missing something in WS-Trust standard?
Im using WIF built-in implementation, so it is 1.3 version of standard with parts of 1.4.
Thanks a lot in advance.
WS-Trust 1.3 and 1.4 uses SOAP Fault mechanism. There are a handfull of faultcodes specified in the standard.
WS-Trust Error Handling
You can use wst:FailedAuthentication SOAP Fault code and provide second-level detail fields to explain password expired situation, but you should be careful not to introduce security vulnerabilities when doing so (e.g., by providing too detailed information).