<kc:bearer-only> and BASIC auth
by Eric Wittmann
[Resending this because apparently I wasn't subscribed to this mailing
list before!]
----
Hey guys. This is in reference to the discussion here:
https://issues.jboss.org/browse/KEYCLOAK-1472
At Bill's request, I'm moving it here.
I think KEYCLOAK-1472 (for us) might have a couple different aspects to
it. So I'm going to focus on just one in this email. And I'll start a
different thread for the other aspect.
We have a REST endpoint located at /apiman which is protected by
keycloak. We need to support both bearer token authentication *and*
BASIC authentication on that endpoint. Our apiman UI uses bearer-token
auth to access the API. However, for scripts and CLIs and other
integrations, we need to allow users to provide BASIC auth credentials
if they so choose.
In any case, here is the relevant config in standalone.xml for this:
<kc:secure-deployment xmlns:kc="urn:jboss:domain:keycloak:1.0"
name="apiman.war">
<kc:realm>apiman</kc:realm>
<kc:resource>apiman</kc:resource>
<kc:credential name="secret">
password
</kc:credential>
<kc:enable-basic-auth>true</kc:enable-basic-auth>
<kc:disable-trust-manager>true</kc:disable-trust-manager>
</kc:secure-deployment>
This works great unless authentication fails, at which point we get a
redirect to the login page. That makes sense if this were a UI, but
it's not. The solution to the redirect problem is to add:
<kc:bearer-only>true</kc:bearer-only>
This fixes the redirect to login page problem but it disables BASIC auth
support.
Can we get an option that disables the login redirect but still allows
BASIC auth to work?
-Eric
8 years, 8 months
KC + apiman + CORS
by Eric Wittmann
Well, I was going to wait on this until I've done some more testing and
really come up to speed. But can have a go at it now with what I know.
After looking into it, we are in fact *not* using the KC CORS support.
Why are we not using it? That's a great question with a real answer...
but it's what I need more time to figure out. Perhaps @msavy has some
insight into that.
In any case, we've implemented our own CORS support for our API (as a
simple filter). However, as you can imagine it doesn't work for
preflighting because KC denies the OPTIONS request since it doesn't
include the auth creds (the browser doesn't send auth creds for
preflight requests).
So I guess we either need to use the KC CORS support, in which case I
need to figure out why we *stopped* using it. Or else we'd need to
request a way to bypass KC auth for OPTIONS requests.
8 years, 8 months
Reset Password changes complete needs review
by Bill Burke
Here's what I did, I can change things based on questions I asked in
other emails, but here's how it works.
There's now the concept of "reset password" and a different one "change
password".
* Reset password is something the user initiates. This will start an
Authentication Flow and success will login the user and bring them to
their application
* Change password is something initiated by an admin. This just sends
an email to the user to reset their password and does not start an
authentcation flow.
Reset Password changes:
* A Temporary Code is included in the Email in addition to a clickable
link.
* When a user requests to be sent an email, they are brought to a new
screen. This screen allows the user to alternatively enter in the code
from the email rather than clicking on a link.
* Temporary codes can only be entered once. If it is entered wrong,
user has to start login process all over again.
* Links can only be clicked once.
* The "Enter code" screen is shown with a success message even if a bad
username or email is entered. This is how it worked before. I'm
guessing this is here to avoid guessing email/usernames?
Change Password changes:
* It is a different email than Reset Password as there is no code
Questions:
* Should we get rid of the "back to login" links and instead have a
"Cancel" button? This applies to registration
* Should "Enter code" screen show a success even if the username/email
was invalid? Do we need to protect hackers from guessing usernames?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 8 months
Time skew in client adapters
by Stian Thorgersen
We recently had someone that had issues with the javascript adapter not refreshing tokens. The reason for this was that the browser and Keycloak server was in different time zones, so exp was not checked properly.
I've now updated the javascript adapter to include a timeSkew property. This is calculated by:
timeSkew = (timeRequestStarted + timeRequestCompleted) / 2 - token.iat
The assumption is that if the request and response takes roughly as long the tokens iat value will be set in the middle of request start and request stop.
This will work both for cases where the browser time is not correct as well as when the browser is in a different time-zone.
Big question is, should we do the same for all adapters? For server-side adapters we can be more assured that the time is in sync (not sure if we mention in the documentation that it's important to keep times in sync), but we still have the issue if the servers are in different time zones.
8 years, 8 months
How to start with development?
by Sebastian Olscher
Hello,
I´ve downloaded the keycloak-src-1.4.0.Final.zip<http://www.redhat.com/j/elqNow/elqRedir.htm?ref=http://downloads.jboss.or...> archive from the keycloak homepage and have imported all maven projects into my IDE. Doing that I was faced with many many projects. My question is now: how to start to get a knowing about what is the responsibility of what project? Is there any overview, any documentation, any architectural diagram which shows how the whole system works? Is there any developer documentation?
Thanks,
Sebastian
8 years, 8 months
Pluggable client authentication, Support for client authentication with signed JWT
by Marek Posolda
I've sent PR https://github.com/keycloak/keycloak/pull/1545 for
#subject. Few main points:
- Authentication of OIDC clients is now pluggable. I've added
ClientAuthenticationSPI and some support classes like
ClientAuthenticator . There is also new flow type
ClientAuthenticationFlow as there are some differences between
authenticating clients and users (ie. for clients you don't have
ClientSession available etc).
- There is new builtin flow "clients" added automatically, which can be
seen in "Authentication" tab in admin console . By default it has 2
executions:
-- Traditional authentication with client_id and client_secret
-- Authentication with signed JWT . It works in a way that client
generates JWT and signs it with his private key . Keycloak then verifies
signature with public key attached to the certificate corresponding to
client . Related specifications: [1] and [2] . I've implemented 6.1 and
6.2 from the [1], which means that clients are able to authenticate
themselves for retrieve service accounts (ie. "grant_type" is
"client_credentials" ), but also authenticate themselves for all other
backchannel requests (code-to-token, refresh token etc)
- In "Credentials" tab in admin console for Client is table with
available authentication mechanism. Admin needs to choose "Client Id and
Secret" or "Signed JWT" . For signed JWT he can either:
-- generate keypair + certificate and download his private key into JKS
or PKCS12 keystore file
-- upload the certificate corresponding to his existing private key .
In both cases is Client's private key not saved in Keycloak DB as
discussed in other thread last week. So just the client is exclusive
owner of his private key and when he loose it, he needs to generate and
download another one.
Possible remaining work:
1) Adapters support? I am thinking about adding simple pluggable SPI
for client authentication on adapter side. It will be ServiceLoader
based and it will choose client authentication mechanism based on the
credentials provided in keycloak.json in webapp. For example when there is:
"credentials": {
"secret": "password"
}
it uses traditional clientId and clientSecret like now.
When there is:
"credentials": {
"jwt": {
"keystoreFile": "classpath:keystore/keystore.jks",
"keystoreType": "JKS",
"storePassword": "secret",
"keyPassword": "secret",
"tokenExpiration": 10
}
}
it will authenticate client with signed JWT . WDYT?
2) Example, docs, polishing, maybe adapter tests . But most of automated
testing is done already. I've added ClientAuthSignedJWTTest for testing
signed JWT and CustomFlowTest for testing custom client authentication flow.
ETA for 1 and 2 are maybe 2-3 days of work. I will show more on the call
on Thursday. WDYT?
Marek
[1] https://tools.ietf.org/html/draft-ietf-oauth-assertions-01
[2] https://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03
8 years, 8 months
refactoring reset password
by Bill Burke
I'm refactoring reset password. I'll be adding a pluggable
"reset-credentials" flow so that users can add things like answering
secret questions before they are sent the email. They will also be able
to remove/disable sending an email and implement their own mechanism,
i.e. SMS.
Our old implementation would just reset the user's password, they would
then have to click back to application and restart the login process.
With flows, I can log the user in. Isn't that a better approach?
The only issue with automatic login is OTP. What should be the default
behavior be here?:
1) If OTP is set up for the user or if required by realm, automatically
set the OTP required action.
2) If OTP is set up for the user and not required by realm, disable
their OTP, let them log in.
3) If OTP is set up for the user or if required by realm, don't
automatically set the OTP required action, let the user login after
successful email
4) If OTP is set up for the user or required by realm, don't set OTP
required action, after successful email, require them to enter in the otp
I think the default behavior should be #1. Without coding, users would
still be able to configure any option above in the admin console by
adding various authenticators to the flow.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 8 months
Abstract SMS support
by Bill Burke
I was thinking that we would create abstract support for SMS support for
Keycloak. We would define a simple Provider interface for sending text
messages. We would not provide anything out of the box for now. We
would require users to implement their own SMS provider and plug it in.
Basically, we'd have an SMS OTP Authenticator for both the browser login
and reset-credentials flows. Keycloak would just send an SMS with a
one-time secret code that you have to enter in. We also would implement
a validate mobile number required action too.
I don't think any of this would take very long (a day or two?) once I
get the reset-credential pluggable-flow support done.
Later on, maybe its something we could integrate with Aerogear UPS out
of the box?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 8 months
