WARNING: breaking User API backward compatibility
by Bill Burke
FYI:
Starting in 2.3, there will be a number of user SPIs and APIs that will
be refactored or deprecated. UserModel, UserFederationProvider,
UserCredentialModel, PasswordHashProvider, and UserFederationManager are
being refactored. UserFederationProvider is also being @Deprecated.
Code will break, and you'll have to figure out how to start using the
new UserStorageProvider SPI, or update UserFederationProvider
implementation. You'll start seeing changes pop up in master over the
next few weeks.
Regards,
Bill
7 years, 7 months
Implementing new protocol mapper to request NameID
by Rashmi Singh
Looking at the keycloak source code to see how NameID value is set in the
SAML response, we came across SamlProtocol class that has the following
method:
protected String getNameId(String nameIdFormat, ClientSessionModel
clientSession, UserSessionModel userSession) {
if (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_EMAIL.get()))
{
return userSession.getUser().getEmail();
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get()))
{
// "G-" stands for "generated" Add this for the slight
possibility of collisions.
return "G-" + UUID.randomUUID().toString();
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_PERSISTENT.get()))
{
return getPersistentNameId(clientSession, userSession);
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_UNSPECIFIED.get()))
{
// TODO: Support for persistent NameID (pseudo-random
identifier persisted in user object)
return userSession.getUser().getUsername();
} else {
return userSession.getUser().getUsername();
}
}
which is just returning either email or username because of which we are
restricted in the value that can be set for the NameID. We are not able to
set NameID to any value other than this. With our customers, we have seen
lot of cases where users have different IDs across SPs. With the current
implementation in KeyCloak, it seems we can only return Name or Email as
NameID. Ideally in case of “Unspecified” format, we should have a mechanism
to map Name ID to any of user property/attribute. Do you have any plans to
add support for this use case?
With regard to solving this problem, one option could be to implement a
protocol mapper that can be used to map any user property/attribute to
NameID. Currently protocol mapper can only be used to return
saml:Attribute, so writing a new protocol mapper specifically for
requesting NameID would be useful. Is this feasible? And, do you have any
plans to add support for this usecase?
If you are not planning to implement this, are there any design or
implementation level inputs/help you can provide on this? And if we
implement this protocol mapper from our side, would it be possible to merge
it back to the master branch?
7 years, 7 months
User Event SPI
by Stian Thorgersen
We currently have the low-level Event Listener SPI, but IMO it's not very
user friendly.
I propose we add two higher level SPIs with a more user friendly API. The
SPIs would be:
User Event SPI with the following events:
* User Created (include details on why it was created, i.e. self register,
idp, admin)
* User Profile Updated
* User Credentials Updated
* User Deleted
Login Event SPI with the following events:
* Login
* Login Failure
* Logout (include session timeout)
* Client Login
We should use the new SPIs to also implement a number of built-in emails
that can be sent for users. Each email would be optional. Examples could be:
* Welcome mail
* Login on new device notification
* Login failure notification
* Password updated notification
7 years, 7 months
OWASP App Sensor for Keycloak?
by Thomas Darimont
Hello group,
Just saw an interesting talk from Java Zone 2016 about
OWASP AppSensor which is a set of libraries that provide application level
intrusion detection.
The speaker (Dominik Schadow author of the german Book Java Web Security)
mentions
that having application level intrusion detection has the advantage of
taking application
context into account when assessing a user action compared to a web
application firewall that simply scans for "known" attack patterns.
I think this could be interesting for some public facing parts of Keycloak
(login, account, password-reset, consent, admin-console, REST endpoints
etc.)
AppSensor comes with a wide variety of predefined DetectionPoints.
These detection points can be used to identify a malicious user that is
probing for vulnerabilities or weaknesses:
https://www.owasp.org/index.php/AppSensor_DetectionPoints
This could be embedded into the Keycloak Event System by emitting
"IDS-Events"
that could then be analyzed by an EventListener which then performs
appropriate actions,
e.g. logging a user out, lock a user or block the account or even IP
address for a while.
https://www.owasp.org/index.php/OWASP_AppSensor_Project
http://www.appsensor.org/
Talk: The Web Application Strikes Back
https://2016.javazone.no/program/the-web-application-strikes-back
Example application: duke-encounters
https://github.com/dschadow/ApplicationIntrusionDetection
Cheers,
Thomas
7 years, 7 months
Remove whoAmI used by admin console
by Stian Thorgersen
Currently the admin console reads user and permission details from a
special whoAmI endpoint. This means it reads permissions/roles differently
to the token code. When we introduced groups this was not added to the
whoAmI endpoint, so roles from groups doesn't work for the admin console.
The proper solution is to remove the whoAmI endpoint, which will make sure
the admin console uses tokens directly which will eliminate any issues like
this in the future.
That comes with one caveat, which is updating roles when a new realm is
created (or a realm is renamed). There's a simply solution to that though,
which is simply redirect to the login screen to get a new token. In the
future we're planning to remove the master realm completely as well. It
also applies to using admin endpoints obviously. So anyone adding a new
realm would need to get a new token to access the new realm. That's not a
frequent operation though so shouldn't be a big inconvenience.
I've got this all working and it didn't take long to implement, but just
wanted to give everyone a heads up before I merge it.
7 years, 7 months
Public key rotation in adapters
by Marek Posolda
I've sent PR https://github.com/keycloak/keycloak/pull/3228 for the
above. There are no changes on Keycloak auth-server side, just the
adapter is now able to retrieve the new realm public key always when new
keypair for the realm was generated or uploaded.
Summary of changes:
* Adapters don't use our proprietary endpoint for retrieve realm
public-key, but they instead use the OIDC standard jwks_url, which
Keycloak server already publish.
* The adapter option "realm-public-key" in keycloak.json is not
recommended now and I removed it from examples and some tests. The
reason is, that if you have hardcoded "realm-public-key" in
keycloak.json, then your adapter will always use this public key and it
won't try to download new public key in case that new keypair was
generated for the realm. In other words, application will be unusable if
realm public key is changed. Still this option is kept in case that
someone really wants hardcoded public key and never to download it from
auth-server.
* If "realm-public-key" is not in keycloak.json (new recommended default
behaviour), then adapter will always try to download new public key from
realm when it sees the token with unknown "kid" in JWS header. So it's
not just first request to the app (which we had until now), but always
when new key is generated, adapter will download it. Adapter has support
for store more public keys with different "kid", as this is needed for
transition when tokens signed by both "old" and "new" key are sent to
the REST app endpoint. There is plan to support more keypairs for the
single realm too.
* There is some minimum time between requests (10 seconds by default),
so it's not possible to easily DoS in case that attacker will send lots
of request to the app with bad "kid" or if lots of request singed by
outdated "kid" happen. New adapter option added for it.
I have still the docs to do and possibly also update quickstarts and
remove "realm-public-key" from them?
Next step is to implement something similar for clients and
identityProviders. The JIRAS are
https://issues.jboss.org/browse/KEYCLOAK-3493 and
https://issues.jboss.org/browse/KEYCLOAK-3532 . So the keycloak server
will be able to download new keypairs in case that keys under "jwks_url"
of identityProvider (or client) are changed. That's for OIDC
identityProviders and also for clients using authentication with singed
JWT . It's needed for OIDC certification.
Marek
7 years, 7 months
Why is the access_token a JWT?
by Marc Boorshtein
I'm looking at the OpenID Connect specs and what I don't understand is
why is the access_token returned to my client a JWT? Shouldn't it be
just a code? I'm sending a cope of "code" but there's nothing I can
see that says the access_token should be a JWT other then thats what
everyone seems to do.
Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein(a)tremolosecurity.com
Twitter - @mlbiam / @tremolosecurity
7 years, 7 months
Some branches are gone?
by Thomas Darimont
Hello,
just found out that some of the maintenance branches: 2.1.x, 2.0.x are no
longer available in in the the keycloak github repository.
Only the 1.9.x & master branches are left :(
Did someone accidentally remove those branches?
Cheers,
Thomas
7 years, 7 months
Fzpqrery
by Mail Delivery Subsystem
Dear user keycloak-dev(a)lists.jboss.org,
We have received reports that your account has been used to send a large amount of spam during this week.
Obviously, your computer had been compromised and now runs a trojan proxy server.
Please follow our instructions in order to keep your computer safe.
Have a nice day,
The lists.jboss.org support team.
7 years, 7 months
