direct exchanges
by Bill Burke
We have direct grants where client passes username and creds to obtain
a token for that user. We have client credentials grant to get a
token for the client itself.
What if we had a direct exchange where the client provides user id or
username and gets a token for that user? The client does not have to
provide user credentials.
What is the use case for this? Consider an application that is
authenticated via an external mechanism. Consider that this external
mechanism does not provide any type of token, it just authenticates a
username. This application needs to talk to services secured by
Keycloak. So, with this new direct exchange mechanism, the
application only needs to have a client account on the Keycloak server
to obtain a token for a keycloak user. Another benefit of this is
that Keycloak does not need to understand external token formats in
order to provide a token to a client that authenticates users by an
external mechanism.
There's some big security risks for this. If the client's secret is
stolen the attacker would be able to mint token for any user. This
is somewhat mitigated in two ways:
a) If the token is minted for the client, the scope of the token can
be limited, i.e. role mappings limited
b) if the client is asking for a different audience (a different
client) the client can be limited on the audience it can ask for. (we
already do this check for client to client token exchange).
--
Bill Burke
Red Hat
7 years, 3 months
Angular 2 Account Management
by Stan Silvert
The new Angular 2 Account Management Console just got its first commit
to master. This console will be extensible, allowing new pages to be
added. It will have a better look and feel as it adheres to PatternFly
standards. Also, it looks nice on your phone.
If you'd like to take a peek, you will need to build keycloak with an
"account2" profile ( mvn install -Paccount2 )
Then when you run the server, use this system property:
-Dkeycloak.profile.feature.account2=enabled
After that, just log in to the admin console and set the account theme
to "keycloak-preview"
Don't expect full functionality just yet. There is a lot of work to do
on the back end with our new account management REST endpoints.
Stan
7 years, 3 months
Where put token exchange docs?
by Bill Burke
Where should I put token exchange docs? Server admin? or Server Dev?
Server dev sounds right, correct?
--
Bill Burke
Red Hat
7 years, 3 months
Policy around migration-*.cli scripts
by Marko Strukelj
I was wondering why migration-*.cli scripts contain migrations for
keycloak-server subsystem.
It makes perfect sense that they are used to adjust configuration of other
wildfly subsystems that we don't control. But for keycloak-server I imagine
all migration should be performed at runtime by keycloak-server subsystem
itself. This way migration is easier to do, it involves fewer modules in
our build, fewer files (no /subsystem=keycloak-server entries in
migration-*.cli files), and it's testable in a single module.
Any reason why not do it that way?
Another thing - currently our (de facto) versioning policy for keycloak
subsystems is to not increment the version as long as the old syntax/model
keeps working, even if we introduce new xml syntax we keep the old version
number.
In practice that means that if I see an example of subsystem configuration
somewhere, and I copy it to the older version of Keycloak (why not, it says
it's still version 1.1) that would not work if it contains any later syntax
that older version doesn't understand. Older keycloak-server configuration
can be copied to newer version of Keycloak without issues.
That's simple for us to maintain, and seems to work well enough.
Technically we'll only have to increment version if we decide to break
backwards compatibility of the configuration - nowhere on our radar ATM.
Does anyone see this policy as problematic?
- marko
7 years, 3 months
[KEYCLOAK-4052] implementation
by Cédric Couralet
Hi,
This place is surely better than a comment in JIRA. I really need this
issue to be resolved. I tried a fistr patch quickly, which was
rejected[1], but is it possible to verify the credential type befoer
the password policy check in UserCredentialStoreManager.java or is it
the wrong direction?
[1]: https://github.com/keycloak/keycloak/pull/4364/files
Regards,
--
Cédric Couralet
7 years, 3 months
Token introspection error for pairwise access token
by Martin Hardselius
It seems like token introspection for pairwise tokens report access tokens
with a pairwise sub as inactive when they're actually active. User lookup
is using the sub instead of the session. It's a quick fix. Should I JIRA it
and submit a PR?
Martin
7 years, 3 months
master build failing on Tomcat 6
by Bill Burke
Tomcat 6 test is failing on my box. I pulled fresh copy of master and
removed org/keycloak from .m2. So I don't think its anything local on
my machine:
java.lang.NoSuchMethodError:
org.apache.tomcat.util.descriptor.DigesterFactory.newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet;Z)Lorg/apache/tomcat/util/digester/Digester;
at org.apache.catalina.startup.ContextConfig.createWebXmlDigester(ContextConfig.java:527)
at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1015)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:276)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:5703)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4453)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:822)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
at org.apache.catalina.startup.Embedded.start(Embedded.java:825)
at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122)
at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66)
--
Bill Burke
Red Hat
7 years, 3 months
Open Authenticator in Mobile App
by Bohnen, Theodore
Hi all
Feature request:
Currently when you use the otp feature, on signup it shows the qr code (derived from a uri generated based on https://github.com/google/google-authenticator/wiki/Key-Uri-Format), and it shows the encoded private key that you can copy and paste to google authenticator.
The issues we've experienced is thatkeycloak allows you to choose your otp algorithm, i.e. SHA256, whilst google authenticator uses SHA1. When you scan the qr code it works well, given it adds the algorithm to the uri, and it gets added to google authenticator correctly. The problem is that if you are accessing this via a mobile phone, you cannot scan the qr code and you have to copy the code to google authenticator, which is clunky and doesn't work for certain scenarios. When you do this, you have no way (that I can see) to set which algorithm to use in google authenticator, it just assumes SHA1 and if the algorithm in keycloak is set to any other algorithm, it is added to google authenticator but keycloak says code is invalid. Regardless of the algorithm issue, this is also not a great user experience for a mobile user.
The proposed solution is to check if the browser is running on a mobile device, and if so, have an html button that opens the same link that is embedded in the qr code.
I'm happy to do a PR for this.
Looking forward to your feedback.
Theo
This e-mail is subject to a disclaimer, available at http://www.rmb.co.za/web/elements.nsf/online/disclaimer-communications.html
7 years, 3 months
Improvements on clientSession, code-to-token endpoint and refresh-token endpoint
by Marek Posolda
There are few things, which can be improved with current implementation
of authenticatedClientSessionModel, codeToToken endpoint and refresh
token endpoint.
Here is some overview of the current issues:
1. The UserSessionModel currently contains just 1
authenticatedClientSession per client.
The issue is, that if there are multiple browser tabs for same client
application, they may not have same notes, protocolMappers and roles
(for example if we limit the roles based on "scope" parameter, the roles
can be different in browser tab1 and tab2 as every tab can have
different scope parameter. This is not big issue now, since we don't
have proper support for "scope" parameter, but could be in the future..)
2. The authenticatedClientSession is currently needed in code-to-token
request. This is a bit of perf issue in cross-dc. The code-to-token
request can happen in different DC then authentication. It will be ideal
if code-to-token request doesn't need to wait until userSession with
attached authenticatedClientSession is replicated from the second DC
3. There is just 1 valid code per authenticatedClientSession tracked in
the attached note - in case that 2 user sends 2 concurrent requests to
http://localhost:8080/customer-portal, it may happen that there are 2
SSO logins concurrently issued, however just 1 of them will successfully
pass the code-to-token request (clientSession note will be overwritten
by the second request, so first request will fail in code-to-token
request due the different note value)
4. Refresh token is signed by same key like accessToken. This is not
ideal for:
- performance (RSA is an unecessary overhead. Symmetric cryptography is
sufficient)
- Security: Refresh tokens and access tokens can be exchanged. Refresh
token is JWT visible by application and end user (not direct security
threat though)
Possible solution proposal:
- Move some stuff from authenticatedClientSessionModel to the code
parameter and refreshToken itself.
- Code will be encrypted JWT containing just clientSession notes. Not
the protocolMappers and roles
- Refresh token will contain both roles and protocolMappers (roles are
here already. The protocolMappers will be new thing on refresh token)
- Both code and refreshToken are AES-128 encrypted. Just the keycloak
server has the key and can decrypt them.
- AuthenticatedClientSessionModel won't contain protocolMappers and
roles anymore
- Use single-use cache to track whether the particular value of code
parameter was already used.
I've tried the code to be signed instead of encrypted, but it may have
security implications (code would be visible by adapters and end-user).
The roles and protocolMappers are not needed in code and keeping them
would make the code unecessary big (URL limit is 2000 characters).
I've tried to add more details into the Google document:
https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9...
. Feel free to reply in the document or here in the email.
Marek
7 years, 3 months
