Keycloak policies eval
by Simão Silva
Hi there,
I'm implementing keycloak for authentication in a server with spring
boot. I'm doing something like "@RequestMapping("/login") " in java but
the policies aren't taken into account, because I can login with every user
in the client. I want something like this
https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-je...,
that tells me if the user can or not access the specific client in a
resource. What should I do?
Best regards,
Simão Silva
5 years
Getting auth request params in script mapper?
by Gary Kennedy
Looking at the AuthorizationEndpoint class I notice that additional authorization request parameters are put in the authentication session client notes.
(https://github.com/keycloak/keycloak/blob/4.8.2.Final/services/src/main/j...)
I would like to work with those request parameters in a (preferably script) mapper to put calculated claims into the access token however I can't seem to find them.
Does anyone have any ideas/thoughts on how I can use the authorization request parameters to put claims into tokens?
Preferably without code customisation/provider; but that's a restriction I can break if needed :)
I thought this would work, but the only note is the issuer ("iss").
userSession.getAuthenticatedClientSessionByClient(keycloakSession.getContext().getClient().getId()).getNotes();
Cheers,
Gary
5 years
Keycloak Integration with Celoxis
by Kevin Perez Moreno
Hello,
I am currently trying to integrate Celoxis into our SSO provided by keycloak. Celoxis is configured to send SAML requests to our keycloak server by using the following IDP endpoint URL: https://xxx.xx/auth/realms/Demo/protocol/saml
However, I am getting an "invalid authn request reason invalid destination" WARN message in keycloak
After changing the log level to DEBUG. I found out that the Celoxis app is sending a SAML with destination URL https://xxx.xx/auth/realms/Demo/protocol/saml?
It seems that a question mark was added at the end of the destination URL. Please see DEBUG traces below. I wonder if this is the expected behavior, i.e., the question mark added at the end of the SAML Destination URL is causing keycloak to throw an invalid authn request error.
If this is the expected behavior, I wonder if there is any workaround to avoid this error (perhaps ignoring destination validation?)
17:06:47,989 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-9) RESTEASY002315: PathInfo: /realms/Demo/protocol/saml
17:06:47,993 DEBUG [org.keycloak.protocol.saml.SamlService] (default task-9) SAML GET
17:06:47,994 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-9) SAML Redirect Binding
17:06:47,994 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-9) <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN_2eca86d4-06b6-45d1-b944-b2e453326418" Version="2.0" IssueInstant="2019-03-28T16:06:47Z" Destination="https://xxx/auth/realms/Demo/protocol/saml?" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://app.celoxis.com/psa/person.Login.do?code=netguardians"><saml:Issuer>celoxis.com</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>
17:06:47,999 DEBUG [org.keycloak.protocol.saml.SamlService] (default task-9) verified request
17:06:47,999 DEBUG [org.keycloak.protocol.saml.SamlService] (default task-9) ** login request
17:06:47,999 WARN [org.keycloak.events] (default task-9) type=LOGIN_ERROR, realmId=Demo, clientId=null, userId=null, ipAddress=x.x.x.x, error=invalid_authn_request, reason=invalid_destination
Thank you in advance
Kevin
[https://cdn.netguardians.ch/images/banner_new_web.jpg]<https://www.netguardians.ch/>
5 years
Authentication Flow Changes in 5.0?
by Craig Setera
I previously created a new action token/set initial password authentication
flow for Keycloak. I know that this was working previously, but for some
reason appears to have stopped working now. The only thing I can think
that has changed was upgrading Keycloak from the 4.8.3 version to the 5.0.0
version. In my code, I'm creating and registering a new
AuthenticationFlowModel instance.
private AuthenticationFlowModel getInitialPasswordFlow(RealmModel
> realm) {
> AuthenticationFlowModel flow = realm.getFlowByAlias(FLOW_ALIAS);
> if (flow == null) {
> flow = new AuthenticationFlowModel();
> flow.setAlias(FLOW_ALIAS);
> flow.setBuiltIn(true);
> flow.setDescription("Set Initial Password");
> flow.setProviderId(AuthenticationFlow.BASIC_FLOW);
> flow.setTopLevel(true);
> realm.addAuthenticationFlow(flow);
> }
>
> return flow;
> }
>
Which is called as part of my handleToken implementation:
public Response handleToken(
> UserInvitationActionToken token,
> ActionTokenContext<UserInvitationActionToken> tokenContext)
> {
> return tokenContext.processFlow(
> false,
> "set-initial-password",
> getInitialPasswordFlow(tokenContext.getRealm()),
> null,
> new
> UserInvitationAuthenticationProcessor(token.getRedirectURI()));
> }
>
However, it does not seem that the password flow is ever executed. It
seems to jump right to authenticationComplete:
* @see
> org.keycloak.authentication.AuthenticationProcessor#authenticationComplete()
> */
> @Override
> protected Response authenticationComplete() {
>
> authenticationSession.setAuthNote(UserInvitationConstants.SET_INITIAL_PASSWORD_AUTH_NOTE,
> "true");
>
> if (redirectURI != null) {
> authenticationSession.setRedirectUri(redirectURI);
> }
>
> return super.authenticationComplete();
> }
>
Were there changes between 4.8.3 and 5.0.0 that would impact the
authentication flow functionality? If so, can someone point me to the
changes as well as any information I might need to know in order to fix up
my implementation to make it work again?
Thanks so much,
Craig
=================================
*Craig Setera*
*Chief Technology Officer*
5 years
Disabling token issuer check
by kapil joshi
Hi All,
While trying to validate 2rd party token in a NATed environment, we are
getting error in verifying the token, due to difference in the issuer of
the token. Getting error like org.keycloak.common.VerificationException:
Invalid token issuer.Expected "keycloak-service-url" but was '
https://boxip:30003/auth/realms/myrealm'
We are using stable helm chart for deploying keycloak.
Actually there is a check to enable/disable realmUrlCheck(i.e the issuer
check). If disabled we are good to go. Then we are able to verify third
party token in NATed environment too.
My question is, will there be any security concern if we disable this
checkRealmUrl check in the adapter.
Thanks & regards
Kapil
5 years
Keycloak with Okta as SAML IdP - Logout
by Lorenzo Filì
Hi,
My configuration is as follows: the web application is a confidential
client connected to Keycloak. Okta is configured as SAML IdP.
Everything works fine, but not for the logout part. Okta requires you NOT
to use the backchannel logout. This way the logout from Okta is done, but
the session and access tokens on Keycloak are not invalidated. Is it
possible to have a Single Logout with this configuration?
Lorenzo
5 years
User federation in KC 5.0.0 duplicating user on some setups
by Leandro Nunes
Hi,
I'm trying KC 5.0.0 running on Java 1.8.0_191 with a newly created Realm
simply set up with a custom User Federation (this was tested running
"standalone.sh" against the H2 database). When I login (I'm using the
"account" client/application but I think this may be irrelevant for this
matter) I get two different results:
- on some computers I can login and logout several times using any given
account. After doing so if I search the user by email in the Users section
of KC's admin console I see a single entry. This is fine!
- on some other computers, however, I can login for the first time but
if I try to login a second time I get a PersistenceException complaining
about Unique index or primary key violation (...) ON
PUBLIC.USER_ENTITY(REALM_ID, USERNAME) (....). If I search for this user's
email on KC's admin console I now see two entries: the one coming from my
external source and an extra create by KC.
This was also tested on KC 4.8.2 with the exact same results. Have you seen
this before? Any ideas about what the problem may be?
Regards,
Leandro Nunes
5 years
(no subject)
by Masseoud Ghassen
--
Cordialement ;
MASSEOUD Ghassen 99402944
Mastère en sécurité réseaux et service
5 years
Display issue in user groups tab
by Ryan Slominski
I'm not seeing that issue. Do you have localization enabled or anything else configured to a non-default value?
Any unusual messages in the log file? You can enable trace logging with:
./jboss-cli.sh --connect
/subsystem=logging/logger=org.keycloak/:add(category=org.keycloak,level=TRACE)
If starting from a clean install of Keycloak begin adding your configuration changes until the problem occurs and then we
will have found the cause.
5 years
