Spring Security adapter
by Д Михаил
Hello,
I'm going to use Spring Session to substitute container specific session managment and clustering session purposes.
KeycloakSecurityContext also will be stored in HTTP session. It means that KeycloakPrincipal with KeycloakSecurityContext wil be serialized and deserialized between requests.
In this case I faced with the following situation:
After successfull authentication
2018-02-14 01:02:52.672 DEBUG 14424 --- [nio-8080-exec-6] f.KeycloakAuthenticationProcessingFilter : Auth outcome: AUTHENTICATED
2018-02-14 01:02:52.672 DEBUG 14424 --- [nio-8080-exec-6] o.s.s.authentication.ProviderManager? ? ?: Authentication attempt using org.keycloak.adapters.springsecurity.authentication.KeycloakAuthenticationProvider
2018-02-14 01:02:52.672 DEBUG 14424 --- [nio-8080-exec-6] f.KeycloakAuthenticationProcessingFilter : Authentication success. Updating SecurityContextHolder to contain: org.keycloak.adapters.springsecurity.token.KeycloakAuthenticationToken at b78d8e87: Principal: user1; Credentials: [PROTECTED]; Authenticated: true; Details: org.keycloak.adapters.springsecurity.account.SimpleKeycloakAccount at 1906910f; Granted Authorities: ROLE_user, ROLE_uma_authorization
-?KeycloakSecurityContextRequestFilter clear?SecurityContextHolder .
2018-02-14 01:02:52.715 DEBUG 14424 --- [nio-8080-exec-7] o.s.security.web.FilterChainProxy? ? ? ? : /customers at position 11 of 15 in additional filter chain; firing Filter: 'KeycloakSecurityContextRequestFilter'
2018-02-14 01:02:52.715 DEBUG 14424 --- [nio-8080-exec-7] o.s.security.web.FilterChainProxy? ? ? ? : /customers at position 12 of 15 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
2018-02-14 01:02:52.716 DEBUG 14424 --- [nio-8080-exec-7] o.s.s.w.a.AnonymousAuthenticationFilter? : Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken at 6fabe8e0: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails at fffe9938: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: 06690a32-ab3f-48d6-8776-de16f5d1ad05; Granted Authorities: ROLE_ANONYMOUS'
As a result I had infinite loop of redirection between my webapp and Keycloak server.
After some investigation I have found why it happend.
When KeycloakSecurityContextRequestFilter check refreshableSecurityContext.isActive() refreshableSecurityContext do not contain KeycloakDeployment ( = null). Thus refreshableSecurityContext.isActive() always false.
public boolean isActive() {
return token != null && this.token.isActive() && deployment!=null && this.token.getIssuedAt() > deployment.getNotBefore();
}
The cause of this situation that RefreshableKeycloakSecurityContext created via deserialization and deployment not reassigned.
I have patch to fix it if you agree with that issue.
7 years, 7 months
KEYCLOAK-4509: OIDC IDP initiated login
by Adrian Gonzalez
Hello,
I would like to raise a thread on OIDC IDP initiated login (or OIDC third party initiated login).
KC supports only SAML Clients for IDP Initiated login (http://www.keycloak.org/docs/latest/server_admin/index.html#idp-initiated... I have an OIDC app, I cannot use this feature.The need has been raised in KEYCLOAK-4509.
I created an ugly PR to implement this feature, my use case is described in [1].In this implementation, I :
- configured IDP initiated SAML between KC and external IDP- and hacked the code to test if the destination app was OIDC. If it was OIDC, then KC makes a plain redirect to the RP app (see also [1]).This allows SAML initiated IDP and conversion to OIDC app.
We could implement that by relying on OIDC 3rd party initiated login.See [3] on how this *could* work.This would allow OIDC third party initiated IDP for OIDC app (but this isn't enough for having SAML initiated IDP for an OIDC app - perhaps there's a solution for handling both OIDC 3rd party ).
wdyt ?
Cheers,Adrian
[1] https://github.com/keycloak/keycloak/pull/4965#issuecomment-373578277.[2]...
| | Garanti sans virus. www.avg.com |
7 years, 7 months
Resource Attributes
by Pedro Igor Silva
Hi All,
People have being asking this for some time and I've sent a PR with the
necessary changes that allow users to define attributes to resources.
This is another important improvement to our policy evaluation engine given
that policies are now able to come up with a decision based on attributes
associated with a resource.
The implementation [1] is pretty much similar to what we have for user
attributes. Please let me know if you have any consideration at this regard.
[1] https://github.com/keycloak/keycloak/pull/5079
Regards.
Pedro Igor
7 years, 7 months
Using Fedora community services to relay GitHub events
by Alex Szczuczko
Hi,
The "Stable CI for Keycloak PRs" (KEYCLOAK-6176) epic team is developing
a bot. This information could be useful for that bot.
keycloak-docs-bot (ASzc/dawbrn) is written around webhooks, and I
imagine the CI bot is too. However, when I needed to deploy I hit this
problem:
- Only internet-facing systems can receive webhooks
- Internet-facing systems are in limited supply within Red Hat
- Almost always these systems can't access the internal network
I solved the problem by deploying the bot on a private VPS, but that's
less than ideal for many reasons. I don't know how the Stable CI team
has solved / plans to solve this, but just yesterday I discovered a
better solution.
The Fedora community has a message bus called fedmsg[1], based on
ZeroMQ. They also have a service[2] that bridges GitHub events to
fedmsg. For example, see this[3] live feed of PR open events.
Anyone with a Fedora account can register their GitHub repos with
github2fedmsg, and anyone can listen to fedmsg. So, we could host all
our stuff internally and still get push events by listening to fedmsg!
Do you think your bot could benefit from this, Pavel and Bruno?
Alex
[1] http://fedora-fedmsg.readthedocs.io/en/latest/index.html
[2] https://apps.fedoraproject.org/github2fedmsg
[3] https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.pr...
7 years, 7 months
Abstract User Adapter Federated Storage & Abstract Idp Authenticator
by Adrien DESBIAUX
Hi everyone,
I would like to get some advices on how to use the "First broker login" flow combined with the Abstract User Adapter Federated Storage.
That means the user is not by default in the local Keycloak DB.
The users from the user federation are NOT imported into the local DB.
Hence the use of the `AbstractUserAdapterFederatedStorage`.
In the case of a Facebook login. The default flow is the "First broker login" flow.
I did implement a custom Authenticator based on the default "First broker login".
So in the `authenticateImpl` function, I would like a user login in with Facebook AND not in the User Federation (external DB) to be created the same way as it would be if it was via username/password.
Long story short, I don't want to have `UserModel federatedUser = session.users().addUser(); federatedUser.setEnabled(true);` and `context.setUser(federatedUser);` but just exit success upon successfully user created on the remote storage.
I did try to not execute those 2 steps however the auth keep failing with "User with ID not found".
By looking at the source code of the `AbstractIdpAuthenticator.java` I found out https://github.com/keycloak/keycloak/blob/ee2d28d589ee62d0e0c0e35dd7bab43...
So that means that if I do not execute the `addUser` and `setEnabled`, I will never be able to register a user from Facebook and complete the auth by using an external user federation?
In short, I don't want to store any user locally when the user connect from Facebook, but the Keycloak source code looks like forcing it.
Is it correct?
I hope I was clear enough in my explanation....
I can provide more details if it is not so clear.
Many thanks in advance for your enlightening on this.
Regards,
7 years, 7 months
Initial client scopes PR
by Marek Posolda
Hi,
I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for
the first iteration of client scopes. I will talk on tomorrow call about
the details and still need to write some more automated tests. But I am
seing PR now if someone wants to take a look.
Summary:
- Client Templates were renamed to "Client Scopes". Some things were
removed from the client template admin console (EG. Theme setting added
recently). Also I've removed some ClientTemplate model properties, which
were never used. Client Scope still has list of protocol mappers and
list of "Scopes" (Roles scope mappings).
- There is new tab "Client Scopes" on client. Here you can assign client
scopes to client. Each client has 2 types of client scopes:
-- Default client scopes -- Those client scopes are automatically
applied when login with the client. Their protocol mappers and "Role
scope mappings" are always used.
-- Optional client scopes -- Those client scopes are applicable just for
OIDC clients. They are used just if they are requested by "scope"
parameter during login
- Under "Client scopes", there is new tab "Default Client Scopes" . This
allows to specify "Realm default client scopes" and "Realm optional
client scopes". The scopes configured here will be added as
default/optional scopes to new clients. Client can override this (Remove
those defaults and add some different client scopes). So it works
similarly to Default Roles.
- Roles don't have "Scope Param Required" flag anymore. Protocol mappers
don't have "Consent required" and "Consent text" anymore. Client scopes
don't have "Full scope allowed" flag. But clients still have "Full scope
allowed" flag for now and it's still ON by default for newly created
clients.
- There are few builtin client scopes added to each realm. There are 4
claims scopes defined in OIDC specification and those are added by
default: "profile", "email", "address" and "phone" with the protocol
mappers corresponding to the claims described in OIDC specification [1].
-- The "profile" and "email" are configured as default scopes and hence
are automatically added to new clients.
-- The "phone" and "address" are configured as optional scopes by default.
-- The clients now doesn't have any protocolMappers added by default
when they are created. I've added "profile" and "email" as default
scopes due it's most close to the previous default protocolMappers we had.
- For SAML, there is "role_list" default client scope, containing just 1
protocol mapper "role list". So both OIDC and SAML clients don't have
any protocol mappers by default, it's driven by client scopes now by
default.
- There is "offline_access" OIDC client scope, which is optional scope
by default. This scope contains just "offline_access" realm role. Due
the fact, that parameter "Scope Param Required" was removed from
RoleModel, the "offline_access" role is now automatically available in
tokens for clients with "Full Scope Allowed", even if no offline tokens
was requsted. But I don't think it's big issue besides a bit bigger
token. Same also already applies for uma_authorization and some other
built-in roles. The fact, that offline token is requested is now driven
by "offline_access" scope. But user should still have "offline_access"
role to be able to receive offline token.
Consent changes:
- Consent screen now doesn't display protocolMappers (claims) and roles,
but instead it displays just client scopes. So by default, the consent
screen contains 2 items "User profile" and "Email address", which
correspond to the "profile" and "email" OIDC scopes.
- There can be still the case, when client has some protocolMappers or
role scope mappings defined on itself. So I've added flag "Display On
Consent Screen" on clients (It's OFF by default) to specify if some
message should be shown on consent screen about claims dedicated
directly to client itself. It's useful especially when client doesn't
have any client scopes as the consent screen wouldn't be displayed in
that case.
- During this refactoring, I've tried to do some cleanup we discussed
before, so I've removed protocolMappers and roles from clientSession.
Instead I've added clientScopes to refresh token. During refreshing
token, it's checked that user still has all the consents, which are in
the refresh token. So in case that user revoked consents in the
meantime, the token refresh will fail. ProtocolMappers and scoped roles
are always re-computed from the clientScopes. So if for example another
claim was added to scope "profile", it will automatically be applied
after refreshed token. I don't see an issue with that. User approved on
consent screen scope "profile" and he may not be concerned what
claims/scoped roles are in profile.
- Migration: In the end I did not change existing clients and did not
remove protocolMappers from them and didn't add default/optional client
scopes to them. The only exception is "offline_access" profile, which is
added as optional to all clients, which had scope to "offline_access"
role. Consents are not migrated - again with the only exception being
"offline_access" consent, so refreshing offline tokens from previous
version still works. The new consent screen is something quite different
than previous one, so makes sense to show it to users again when they
want to login, even if they approved protocolMappers for the previous
version.
Sorry for long email and long PR :) More tomorrow...
[1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Marek
7 years, 7 months
first broker login always shows: "your already logged in"
by Naftali van der Loon
Hi, If i configure a new google broker, it always shows: "your already
logged in"
It seems to never redirect back to my application.
The logging shows the following warning:
Not present cache item for key LoginFailureKey [ realmId=mgb.
userId=1178a3e9-f20a-4564-b921-22e196b6ab9b
If I try to login again from my application, I get an unexpected error.
logging shows:
ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (default
task-17) Failed to make identity provider oauth callback:
org.keycloak.broker.provider.IdentityBrokerException: No access_token from
server.
at
org.keycloak.broker.oidc.OIDCIdentityProvider.verifyAccessToken(OIDCIdentityProvider.java:444)
With some more logging I see that a POST request to
www.googleapis.com/oauth2/v3/token returns a 401 Unauthorized
the following request params were sent:
code=4%2FAADq7hCNFYS8Sn5fSaKTO-Z4NFsWp8dt-_rxDFfI9zV5by4zeKLKy9EIw-1S0xD7WZs8O2lIwVQpbYdhv-eRcDc&grant_type=authorization_code&client_secret=**********&redirect_uri=https%3A%2F%
2Fsecure.mydomain.nl
%2Fauth%2Frealms%2Fbloxsense%2Fbroker%2Fgoogle%2Fendpoint&client_id=
770468752706-kvjr3kjmi12uokbe30ldpu4lt43k05vm.apps.googleusercontent.com"
I tried using stickie sessions in my loadbalancer, there is no difference
in behaviour..
This is a HA setup using the helm chart
Greetz
Naftali
7 years, 7 months
Maven dependencies for custom ActionToken implementation
by Felix Peters
Hi,
i try to implement a custom ActionToken. I want to deploy the Module via wildfly-maven-plugin.
This works like expected. No errors when i run "mvn clean install wildfly:deploy". But when i try to instantiate a ActionToken i get the following exception:
Uncaught server error: java.lang.NoClassDefFoundError: Failed to link my/package/actiontoken/TestActionToken (Module "deployment.keycloak-actiotokentest-1.0-SNAPSHOT.jar" from Service Module Loader): org/keycloak/authentication/actiontoken/DefaultActionToken
In my pom.xml i have this dependencies for Keycloak:
<properties>
<keycloak.version>3.4.3.Final</keycloak.version>
</properties>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-core</artifactId>
<scope>provided</scope>
<version>${keycloak.version}</version>
</dependency>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-server-spi</artifactId>
<scope>provided</scope>
<version>${keycloak.version}</version>
</dependency>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-server-spi-private</artifactId>
<scope>provided</scope>
<version>${keycloak.version}</version>
</dependency>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-services</artifactId>
<version>${keycloak.version}</version>
</dependency>
In the quickstart example (https://github.com/keycloak/keycloak-quickstarts/blob/latest/action-token...) they have the keycloak-services dependency not in the provided scope. I tries to use this scope and i removed it. But i always get the same error.
So what dependencies do i have to define if i want to implement a custom ActionToken? I think it's the keycloak-services, but i can't find details about that.
Is the keycloak-services a provided artifact or not?
Thanks for your help,
Felix
7 years, 7 months
