Linking social accounts
by Marek Posolda
I've sent PR https://github.com/keycloak/keycloak/pull/275 for
linking/unlinking social accounts into already existing Keycloak user
account.
I've created another JIRA https://issues.jboss.org/browse/KEYCLOAK-354,
which will allow that administrator will be able to see, which social
networks are connected for user 'john'. We discussed with Stian that
read-only possibility for admin is probably sufficient (ie. admin can
just review that john is linked to Facebook and Google, but he doesn't
have possibility to remove this linking or add new linking of this user
to other social networks).
There is also this bug https://issues.jboss.org/browse/KEYCLOAK-334,
which means that users registered through social can't change their
passwords because changing password requires filling already existing
password and user 'john' doesn't have existing password when he
registered himself through Facebook... It seems that for user without
password, there should be possibility to skip the need to fill existing
password. Maybe there should be new model method like:
boolean RealmModel hasPassword(UserModel user);
or even more flexible:
boolean RealmModel hasCredential(UserModel user,String credentialType);
Not sure if this is sufficient though, because users registered through social won't need to fill existing passwords, which could mean that someone can hijack their session as Stian pointed.
So I was also thinking if we can require that users will need to fill
their password if they are registered through social. Maybe some
administrators don't want this, but in fact many sites on Internet
requires this for Social registration and in fact that's what I did in
GateIn portal as well.
So I wonder if we shouldn't remove the realm boolean attribute
"updateProfileOnInitialSocialLogin" and add new attribute like
"socialRegistrationRequiredActions", which will contain array of
required actions after social registration. So for example:
- If administrator wants users to be registered automatically through
social without need to confirm anything, he can use empty array (same
like currently updateProfileOnInitialSocialLogin=false)
- If administrator wants users to confirm their attributes (firstName,
lastname, email...), he will just add action UPDATE_PROFILE (same like
currently updateProfileOnInitialSocialLogin=true)
- If administrator wants users to confirm attributes and also fill
password, he will add both UPDATE_PROFILE and UPDATE_PASSWORD into this
array
wdyt?
Marek
12 years
why authenticate clients?
by Bill Burke
A good read:
http://tools.ietf.org/html/rfc6749#section-3.2.1
I was thinking about our current client-secret requirement. I don't
think there is any security hole if you are doing the OAuth protocol
over SSL, you are validating redirect_uris and the client sends its
"client_id" when obtaining an access token.
* Keycloak server ensures the access code is transmitted to a valid site
by verifying/validating the redirect_uri sent.
* Since you're using HTTPS, the browser ensures the site is valid by
checking it's cert.
* If you send the "client_id" when obtaining the access token, the auth
server can verify that there was no access code substitution.
One of the uses described in 3.2.1 is that it is easier to reset a
client's credentials than invalidating all the refresh tokens sent to
it. I'm not so sure that is true. If there were a per-app/per-oauth
client Not-Before setting, we could check this on a refresh request.
Any counter arguments to these assumptions? I'm going to see if anybody
on the oauth email list will verify these assumptions.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
Navigation inconsistency
by Gabriel Cardoso
I was exploring Keycloak console and saw some navigation inconsistency.
When the user is in the Roles page, the top navbar is shown (General, Social, Roles…):
When he clicks to add a Role, the top navbar disappear. Since he is just one level deeper, the navbar should NOT be hidden.
This behaviour happens in other situations, when in “addition” pages. Was this planned or is it an error that we want to fix?
Gabriel
--
Gabriel Cardoso
User Experience Designer @ Red Hat
12 years
Support for installed applications added (including example)
by Stian Thorgersen
Support for installed applications in form of two special redirect uris (urn:ietf:wg:oauth:2.0:oob and http://localhost) has been added.
There's also a basic example. To try it out start the server as normal, create an app for it (mark it as public). Download the keycloak.json file. Then run:
# mvn -pl examples/demo-template/customer-app-cli install exec:java -Dexec.args="<path to keycloak.json>"
You can then run different commands to try it out. It has two different ways to login the user:
* login-desktop: this opens a ServerSocket on a local port, opens the login url in the browser, after login the ServerSocket is used to retrieve the code
* login-manual: this uses the 'urn:ietf:wg:oauth:2.0:oob' redirect to display the code in the browser and the user has to manually copy/paste this into the application
12 years
discontinuing scope param
by Bill Burke
OpenID Connect has its own format for the scope param that interferes
with ours. I'm discontinuing our support for it. Scope param will just
be ignored now.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
public clients and wildcard redirects
by Bill Burke
Added support for public clients and App/OAuth Client wildcard redirect
urls.
* Login will fail if you have a public client and no redirect url configured
* For confidential clients you can now use basic auth or form based
authentication based on OAuth 2 spec.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
session mgmt in
by Bill Burke
You can now view open session stats for all applications on one page.
You can then drill down and see what users have sessions open on the
application. You can also view which applicatins a user has open
sessions on. From all these different pages you can perform remote logouts.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
