Authentication SPI - Pinning the IDP
by gambol
Hiya
Hopefully someone know's a way around this ..
We have a requirement to pin a keycloak client to a specific group of login
options i.e. they can only login via a social provider and not a local
username/password, BUT we also wish to allow certain users the ability to
override the behavior. I mocked up authenticator which used the
IdentityProviderSpi.IDENTITY_PROVIDER_SPI_NAME checked it against the a
configurable list for the authenticator and also looked for a user override
attribute. Now on first login that works fine, but as the access token
comes up for refresh the IdentityProviderSpi.IDENTITY_PROVIDER_SPI_NAME is
not retained (i guess because it's now a sso session refresh and not a
login) and so the authenticator throws the error message.
Is it possible to hook into login only? .. Anyone think of another way
around it? :-) .. I tried using SetClientNotes / SetAuthNote to retain the
logged in provider, but that doesn't appear to work either.
Disclaimer: I know the official stance would be the IDP provides
authentication only with authorization handled by the application end, but
in many case's third party applications can't support this .. so was hoping
we could control it at source.
Rohith
5 years, 10 months
Keycloak testsuite artifacts on maven, for module testing
by Doswald Alistair
Hello,
Are the keycloak testsuite artifacts pushed to a public repository? Or if not, would it be possible to publish them alongside the other keycloak artifacts?
We are currently updating the cloudtrust keycloak modules to the latest version of keycloak, and as a part of that we are moving the tests from mocks to arquillian. Since there's a lot of great work already done, we reuse the keycloak testsuite artifacts for this. For our purposes this is fine (we have them cached in our local repository), but for anybody who wishes to build our modules from github it's a bit more cumbersome. On a more general level, it would probably also help other module developers who wish to unit test with arquillian.
Best regards,
Alistair
6 years
passing saml authentication context to custom authenticator
by Gideon Caranzo
Hi Guys,
Is there a way to get SAML authentication context in custom authenticators?
In the code, looks like it's not possible since it is not set anywhere in
AuthenticationSessionModel. So if this is true, what would be the best way
to pass it considering it may contain multiple information?
It can be set as client session note just like other values from SAML
request, but there has to be a way to serialize and de-serialize it since
it's a complex object.
What approach do you recommend?
Thanks,
Gideon
6 years
Issue with CORS on Keycloak (RH-SSO)
by Joao Paulo Ramos
Hi guys,
Sorry if it's not the correct place to make this question (please guide me
to the correct place).
I'm facing some problems with CORS when using rh-sso 7.1.
I'm using the following environment:
- JBoss EAP 7.1 with Resteasy in the backend ->
localhost:8080/accountmovement/api
- ReactJS in the frontend -> localhost:3000
- RH-SSO (7.1 and 7.2) -> localhost:8180
The JBoss EAP is using the Wildfly/EAP Adapter from Red Hat, with the
configurations made on the standalone.xml file as a subsystem:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
<secure-deployment name="accountmovement.war">
<realm>demo</realm>
<resource>accountmovement-backend</resource>
<use-resource-role-mappings>true</use-resource-role-mappings>
<public-client>true</public-client>
<auth-server-url>http://localhost:8180/auth
</auth-server-url>
<ssl-required>EXTERNAL</ssl-required>
<enable-cors>true</enable-cors>
</secure-deployment>
</subsystem>
I Already enabled the Web Origins to " * " in the RH-SSO Admin console for
both of the clients I'm using.
The error I receive is the following:
""
Failed to load
http://localhost:8080/accountmovement/api/accounts?_=1543522008489:
Redirect from '
http://localhost:8080/accountmovement/api/accounts?_=1543522008489' to '
http://localhost:8180/auth/realms/demo/protocol/openid-connect/auth?respo...'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is
present on the requested resource. Origin 'http://localhost:3000' is
therefore not allowed access.
""
Do you have any idea for what can I do?
If you need more information just let me know!
Thank you,
JOÃO PAULO RAMOS
BUSINESS FINANCE - DATA SCIENCE INTERN
Red Hat Brasil
jramos(a)redhat.com M: +55-11-96505-6159
<https://red.ht/sig>
6 years
Interactive claims gathering flow
by Aingaran Pillai
Hi,
We are looking at adding support for UMA2 interactive claims gathering flow
to Keycloak (which I assume is currently not in the supported). We are a
small consultancy that have implemented keycloak extensively but never
extended it. Is this an area we can contribute developer time with some
mentoring from the community? If so where would we get started?
Regards
Ainga
--
This message should be regarded as confidential. If you have received this
email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy
by an authorised signatory.
Zaizi Ltd is registered in England and Wales
with the registration number 6440931. The Registered Office is Kings House,
174 Hammersmith Road, London W6 7JP.
6 years
Issue with concurrent SSO login to same client in more browser tabs
by Marek Posolda
Hi,
I've sent PR https://github.com/keycloak/keycloak/pull/5736 to fix the
issue in subject (corresponding JIRAs are KEYCLOAK-7774 KEYCLOAK-8438).
The cause is that once the user is authenticated in the browser and has
userSession, there is just 1 clientSession per the userSession+client.
So in case of concurrent SSO login in more browser tabs, there can be an
issue that each tab is writing it's state to the same clientSession,
which causes conflicts (especially attributes like nonce, scope or
redirectUri can be possibly different for each tab and shouldn't be
shared).
The possibility can be to revert back when we had more clientSessions
per userSession+client. I think this is step back and has lots of other
issues (memory consumption, more cluster and cross-dc writes, worse
performance in general...). For the future, it will be rather ideal to
remove clientSession entirely or reduce their size even more, as they
will be needed for logout, but hopefully for nothing more.
So the other possibility is to move most of the state to the "code"
parameter and to the refreshToken. Each browser tab has it's own "code"
and it's own refreshToken. Problem with the "code" is, that it's used as
query parameter in the URL and hence has limits for it's size. It seems
ideal is still to stick with 2000 characters per URL. And when
redirectUri itself will be part of the code, it can be problematic as we
don't know how the redirectUri provided by users will be big....
Fortunately refreshToken doesn't have this issue as it needs to be
always sent in the POST request.
So to solve the issue for "code", I've added an entry to the infinispan
cache "actionTokens", which encapsulates needed state and it's supposed
to be valid just for the very short time (between the
AuthenticationResponse to the application and the time when application
sends the code-to-token request) and it's lifespan corresponds to realm
code lifespan (1 minute by default). In the code-to-token request, there
is a call to "cache.remove" to remove the code. Infinispan caches
(local, distributed and hotrod caches) fortunately guarantee that
"remove(123)" is always successful just in 1 thread (Successful means
that it returns previous state). So we still have guarantee for the
single-use code.
Marek
6 years
Remove TokenManager.verifyAccess method?
by Marek Posolda
Right now, during each token refresh, we're verifying if the newly
refreshed access token still contains all the roles, which were present
in the refresh token. If not, the refresh token is rejected.
I wonder if this check can be removed? This will also allow us to remove
the roles (realm_access and resource_access claims) from the refresh
token. Anyone knows a reason if this check can't be removed?
I think the reason why this check was originally added is due the
consent. Previously we did not have clientScopes and the consents on the
consent screen were represented by individual roles and protocolMappers.
However with clientScopes, this seem to be obsolete IMO.
During token refresh, we should check that consents represented by
clientScopes in the refresh token were not revoked by the user (or
admin). If they were rejected, the refresh token should be rejected.
We're doing this. However if some individual role was removed from the
user (or from the role scope mappings), I don't see an issue with
successfully refresh token and just ensure that the revoked role is not
in the new token anymore.
WDYT?
Marek
6 years
Register new ProviderFactorys to Mappers
by Chris Brandhorst
We have developed a customised OIDCIdentityProviderFactory and OIDCIdentityProvider because some IdP does not fully adhere to the standards. However, when using this Provider, the UserAttributeMapper (and other mappers) are not used because they have a fixed list of COMPATIBLE_PROVIDERS.
We would suggest adding a registerCompatibleProvider to the IdentityProviderMapper in order to extend the usage of these mappers.
Just checking before we take the effort of creating a nice PR: is this something you would see fly? If yes, would you suggest changing COMPATIBLE_PROVIDERS to a List<String> or a List<IdentityProviderFactory> and subsequently changing the getCompatibleProviders() implementations?
Thanks,
Chris
6 years
