I would like to add custom attributes to a Keycloak client, similar as we already have "Valid Redirect URIs" which we can easily configure in the Keycloak admin console.
To be more specific - i would like to configure such attributes as "Error redirect URI", which i would be able to access in a custom auth extension f.ex. from the ClientModel.
Is this possible?
Note: I have already tried creating Protocol Mappers (like hardcoded claim), but this feels like a bad workaround and is more on the user level not a client level.
Related
I have an application that includes Keycloak as the identity component. I want to redirect to the Keycloak security admin console for a particular realm from my application, which I am able to do, however I also want to specify a particular IdP to sign in.
For my OIDC apps that are protected by the same Keycloak realm, I am able to do this using the kc_idp_hint query param. However the built-in clients don't seem to respect this, so the following URL does not result in the IdP hint being propagated to the authorization URL:
https://<keycloak>/admin/<realm>/console?kc_idp_hint=<idp>
I built a login system using Flask OIDC and Keycloak. In my system, there is some endpoints decorated with oidc.require_login() that calls the Keycloak login page.
My goal is, after the user successfully logged in, my system checks if the user name exists in a specific database.
How can I set a function to be called every time someone successfully logged in with Keycloak and do this verification at the database?
According to your needs there are several ways to create the user in the backend.
The easiest way would be to just check the JWT token on every request. OIDC is based on JWT and that token is available on any request (which should already be done to find user roles etc). So your application can check that JWT and extract the username from it (see here for details about the JWT format). With the username you can check your internal database and create the user, if it doesnt exist. But at that time you'll not have access to any user credentials any more. It is just SSO and you need to trust Keycloak and the JWT... Also - you'll never be informed, if the user will be deleted in Keycloak, which could be an issue.
There is a callback API in Keycloak in form of the Admin URL per client. But the documentation is not clear. It says: It’s used by the Keycloak server to send backend requests to the application for various tasks, like logout users or push revocation policies. But I cannot find a complete list of "tasks". I saw only logout events. see Keycloak documentation and the documentation only talks about that. If I add an admin url to a test client, I did not get any requests at login time.
a different but more complicated way would be to create your own UserStorage SPI in Keycloak. It would be Java of course, but only some classes. There is an HTTP example or have a look at the LDAP user storage SPI, which supports registration too. If you choose that for your realm and a user tries to login to Keycloak (Login form), the SPI can call your backend to check the user. It also could be "used" to create the user in the backend by checking the Keycloak local storage and only if there is a local Keycloak user, call the backend. That isn't the reason, why you should implement the UserStorage SPI, but it's possible. If you think, this is a good idea, I would prefer to use your backend storage as the one and only storage or build a different one, that then could call your real backend in case of a new user. I would use this one by not using Keycloak local stored users but, by using your own database.
next (maybe last one). You can write an EventListener SPI to read all events and only filter the login events, see here and here. I think, that would be the easiest one. But be aware. In that case, the HTTP call to your backend coming from the event itself is based on a normal HTTP request (without OIDC at that time).
The last two examples create a JAR (which is explained in the links). That JAR with the SPI must be deployed in keycloaks standalone/deployments folder. The EventListener should be active by default, the UserStorage SPI must be activated per realm.
But - be aware - Keycloak/SSO/JWT - should not be used by creating users in multiple backends. Syncing the users between all backends in a SSO environment is maybe the wrong way. Most information is located in the JWT or can be called by a backend from one central user identity management. Do not store a user more then once. If you need the user reference in your backend - link just to the username or userid (string) instead of a complete entity.
There is no direct way of doing this, other sotfware like Openam, Okta allow you to trigger specific flows in a post-login configuration.
In keycloak, you can try to create your custom authn flow(using Default Identity Provider, its the only option that allow a redirect), and then select this flow in your Identity provider in post login flow.
The idea here is that after login, the user will be redirected to a link ( an api call that will verify his presence on the external database, and sent him back to keycloak once the verification is done.
More info here
I'm using Shiro and have a custom realm. My app has many users in a database, and I also want to support non-user process accounts for API access. In my realm, I have implemented:
public boolean supports(AuthenticationToken at)
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken authcToken)
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals)
This works great, we have a login form and process the UN/Password no problem.
I want to allow certain users to be able to use basic HTTP auth, and the rest to use form auth that is already working. I can set the INI to allow either method but I don't see how to implement a check for the type of authentication used in the realm.
If I get a login attempt for a non-api user authenticated via HTTP headers, I want to reject the request.
How do I do this, write a filter and check for the HTTP header is the only way I can think of.
I did the following to make this work:
Add an "api" role to certain users
Create another Application class and set its ApplicationPath to /api for the REST endpoints I wanted to expose
Restricted the /api path to authcBasic, role[api] in the shiro.ini file
This works great. Here are details: http://blog.mikeski.net/blog_post/470
I've set up an IdentityServer3 server with IdentityManager and MembershipReboot and have successfully managed to implement Bearer authentication across a few different ASP.NET Web API servers and a couple of Angular JS clients.
I'd like to be able to set up an endpoint on the IdentityServer3 Web API project itself that users can go to in order to edit their email-addresses, password, etc. In order to do this, I need to be able to use the [Authorize] attribute inside one of the controllers running on the IdentityServer3 server. I'm having trouble trying to find out how to do this.
In projects that use my IdentityServer3 server, I simply add something like:
app.UseIdentityServerBearerTokenAuthentication(...);
I wondered if I could just do the same in the server itself, but it wouldn't be Bearer token authentication in this case.
I just want to add an MVC page to the auth server that I can redirect to from the client applications to allow the user to modify their details. How can I achieve this?
There's an OWIN Context Environment extension in IdentityServer3, namely GetIdentityServerFullLoginAsync, which retrieves the logged in user (stored in a cookie).
I can create a new Action that uses this to retrieve the logged in user and display their details. I can also add endpoints for updating the password, etc, so long as I protect against CSRF in the usual MVC way.
How can I bypass Apache Shiro authentication and just use the authorization scheme. The reason I would like to achieve this is because I am using an in house SSO Authentication written for our cloud application and I would not like to save user information on our application server apart from basic user id and roles.
Implement custom realm (e.g. extend JdbcRealm class) and override doGetAuthenticationInfo and authenticate user within tthat method in any way you want. Of course depending on your authentication method you might have to modify the authorization bit as well (e.g. change the authorization query or even whole DB structure).