It is possible to prevent Keycloak from creating default Clients (e.g. account, account-console, admin-cli) in the new Realm? I init my Keycloak from realm-export.json using Docker.
I removed default Clients from realm-export.json and add own, but the result is both exist in Realm.
It's essential for Keycloak that you don't remove the built-in default clients. It may cause exceptions on some points.
If you don't need them, just disable them, but don't delete!
Related
Keycloak configuration and data is stored in a relational database, which is usally persisted to the hard disk. This includes data like realm settings, users, group- and role-memberships, auth flows and so on. But the user sessions will only be stored in an ephemeral in-memory infinispan cache. Therefore the session data in this cache is lost, when the keycloak server restarts.
There are many reasons why a restart of the Keycloak server is required. Major OS upgrades, Keycloak server upgrades to new versions, applying changes to keycloak e-mail templates or re-scheduling keycloak pods to other worker nodes in kubernetes or other cloud-based environments.
How to persist the session data to survive restarts. Ideally without having to maintain a custom infinspan server or using keycloak "offline sessions".
One solution could be to simply use so-called keycloak "offline sessions", but these sessions also have huge disadvantages:
they remain valid, even if the user logs out
logging out users with the keycloak admin console is no longer possible
See: https://www.keycloak.org/docs/latest/server_admin/#_offline-access
Will this problem still be present when keycloak > 17 is out and uses the all new quarkus distribution? Because in the following articles claim goals like Container-First Approach, Zero-Downtime Upgrade and Storage re-architecture.
https://www.keycloak.org/2021/10/keycloak-x-update
https://www.keycloak.org/2020/12/first-keycloak-x-release.adoc
We are currently deploying to AppSync using the serverless-appsync plugin and the serverless-framework (naturally).
Our API is 100% public and unauthenticated. All queries and mutations are basically public, since we have at this point no need for users (via a Cognito pool for example).
We have added a first layer of security using api keys but this is undoubtedly not much, as the api key is included as-is in the frontend sources. We would like to add extra roadblocks to make it harder for malicious users to abuse that frontend API.
A few things come to mind:
rate limiting (not currently supported by AppSync but I've read it's apparently in the works). I do not want to do this using a custom made solution in a Lambda for example.
making sure only traffic from the website is allowed to use our API, in addition to our own devs... I could probably do this with pipeline resolvers but I am not too keen with doing that in that obscure and unwieldy VTL language.
cors, ...
I'm considering switching to Apollo Server since this solution seems more open and configurable...
I would recommend using AppSync's IAM auth option and then use Amazon Cognito Identity Pools to vend temporary AWS credentials to your client applications. Identity pools (as opposed to user pools) vend temporary AWS credentials that assume the access of a role of your choosing. When configuring the identity pool, you can define a role with full access to the AppSync API or you may selectively provide access. From the client applications, you use the temporary credentials to sign the requests to AppSync using SigV4 and AppSync will only allow requests with a valid signature to be executed. The temporary credentials also provide an extra layer of security as even if they are compromised, each credential will only provide access up to the max allowed time.
I'll also add that you can use multiple auth modes at once with an AppSync API. This allows you to protect all fields as mentioned above and then selectively mark specific other fields such that they are authorized via some other mechanism like user pools or OIDC.
I have 2 applications : the first one is written with ruby (It's redmine) and the second one is a Spring boot app and both are hosted on the same tomcat server.
How can i do that?
Sharing sessions is not allowed. By (servlet spec) definition, a session belongs to a single web application.
Reference: Servlet Spec 4.0, section 7.3:
HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.
There are ways you can probably work-around this limitation by setting-up shared caches, etc. but it will always be brittle and potentially dangerous from a security or resource-usage perspective.
User database or user data file(nosql) with use of a unique-user-auth-token, accessible by two apps (or 3, 4, 5 ...)
Global concept :
App request connection :
is exist "old auth token" in app storage ?
yes -> app send old and request new or same if not expired
no -> continue
is exist valid auth token on server ?
yes (an app is already connected) -> send validated auth token to app
no -> set new auth token and send to app, new AT is ready for other app
server store what app request connection and is connected
apps are now able to exchange datas via the server.
Sharing Web applications is, at a minimum, Bad Practice (TM): Web Applications are completely separated by design. If both applications easily could reach into each other's session: Imagine what would happen if one would overwrite values that have been set by the other, and both applications expecting different data under the same key name.
If you only need single-sign-on, there's a SingleSignOnValve available that will make sure you'll only need to sign in once (provided that you authenticate through the container, e.g. a Tomcat Realm). Check server.xml for the commented-out-default-value, or the documentation for more information on authentication and the valve.
You might work around it by implementing the UI in both modules and refer back to a common business logic, but this is a level of architectural change too broad to fit into this answer.
To meet security requirements, our project needs to move our GeoServer credentials(account/password) out of the code base. Is it possible to authenticate REST calls with certificates, or any other method besides account/password credentials?
The answer is 'yes'!
Exactly how requires working out a few details. If all users are required to provide a certificate, you'll likely want to sort that out at the container level (Tomcat, Wildfly, etc).
Once GeoServer has a certificate, you'll likely want to set up a role service to map users to roles.
The docs for GeoServer's security system are great. I've read them multiple times, and I'd strongly encourage checking them out: http://docs.geoserver.org/latest/en/user/security/index.html#security
Since you mentioned certificates, I'd suggest reading this tutorial: http://docs.geoserver.org/latest/en/user/security/tutorials/cert/index.html.
Since you mentioned security REST endpoints, I'd point out
http://docs.geoserver.org/latest/en/user/security/rest.html. I believe some of that configuration can be done through the GeoServer admin UI.
As a note, GeoServer is highly modular; you may need to install a module or two to connect to an LDAP server or modify how the security settings, etc.
i'm designing a security module for a web application using spring security . There are 3 separate wars(3 Apps)using separate login, deployed in a JBOSS Server.
The requirement is , If the user is authenticated in one app then he should be able to access other applications without login . Is it possible to share the security context between the web application( different wars not in a single EAR ).
We discussed about the SSO , but we are trying to achieve this with spring security and with support of the App server . Is there any way ? Please provide your valuable suggestions and inputs.
If you need more information, please let me know.
The easiest way is to employ usual Spring Security authentication (e.g. form-based with username/password) and enable the remember-me feature.
As long as all three applications are deployed on the same domain (and can therefore share their cookies), the remember-me feature will work seamlessly for all of them, i.e. once user authenticates at any of the applications she will be able to access the others without need for re-authentication.
This of course doesn't address issues like single logout, but that doesn't seem to be your aim anyway.
You can set this up in a short time and don't need and third party SSO components. Although relaying on standard SSO protocols and dedicated technologies tends to be a more secure option.
I've done this recently with SSO and Spring Security however I wrote our own security filter to be used which grabs the HttpServletRequest.getRemoteUser() value provided by the SPNEGO filter. One thing with SSO: most mechanisms use Kerberos which only really works in local desktop environments. It is possible to write a fallback mechanism which will redirect the user to a login page but then you still have your issue at hand.
Another option would be to repackage your applications as an EAR (see here).