iOS Keycloak demo
by Christos Vasilakis
Hi everyone,
worked out a simple application that utilises AeroGear iOS OAuth2 adapter to go against a Keycloak server. You can find the source code here[1] and a small video demonstration here[2].
Overall it worked great but needed to make some small adjustments on the library which I would like your feedback. Two issues that raised are in the request parameters:
- the ‘scope’ parameter on the request needed to be in a specific format "realm": [ “user”, .. ]. Needed to include ‘realm’ and a list of separated names. Not sure if this is the same as the ‘scope’ parameter in OAuth2 where just a space delimited strings are required. Further, the scope needed to be base64 url encoded in order for the server to parse it.
- the ‘client_secret’ parameter needed to be encoded as ’secret’.
Note that this was my first experience with keycloak and possible I am missing some details, but would be really happy to hear your thoughts and suggestions.
As a final note, I really like the ‘Installation’ JSON copy paste on the examples and have the client lib work out the details. I think on the iOS side we can offer similar experience where the user installs the *.json and have the library pick up the configuration details. Something to look at.
Keep up the good work!
Thanks
Christos
[1] https://github.com/cvasilak/KeycloakDemo
[2] https://vimeo.com/87862111
10 years, 2 months
Refactoring Model
by Bill Burke
I'm refactoring ApplicationModel and OAuthClientModel to inherit from
the same interface, ClientModel. I'm moving all the app/client specific
attributes out of UserModel and into ClientModel.
I also want the TokenService to be dealing with ClientModel instead of
putzing around with UserModels and figuring out if they are apps or not.
right now, if you change an application name it can screw up
everything when generating a token.
So, expect some changes in this area this week.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months
1.0 Final roadmap
by Bill Burke
What's left for must-have features before we can start pushing for a
1.0.Final release? We need to release 1.0 sometime in June.
* Minimal OpenID Connect support
* Import/Export of various items of a realm (for data migration).
* Aerogear bootstrap requirements
* Theme support for admin console so we can brand it.
* Revocation policies. I'm thinking Not-Before is good enough for a 1.0
release. We need to be able to push this to deployed apps. And also
maybe piggyback this information in AcessTokenResponse. This also of
course needs to be stored within subsystem config too, or maybe we could
just have adapters pull that information from server at bootup.
* Remember Me for social logins
* Federation of users/credentials with LDAP/AD. Hopefully through
Picketlink.
* User session management. Admin can logout a user.
* Audit log.
Scaling/Optimization:
* Storage cache for the token service so it doesn't hit the database.
* Make token service stateless for clustering environments (maybe don't
need for 1.0?)
We'll stick with only AS7/EAP/Wildfly adapters for 1st release. We also
have to pencil in time for weeks of test writing, benchmarking, and
documentation.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months
Realm admin permissions added
by Stian Thorgersen
Realm admin permissions added has been added to master.
A quick overview on how it works:
When a realm is created an application is created in the keycloak-admin realm. The application name is '<realm name>-realm'. This application represents the roles associated with the realm, and let's you add role mappings to users as well as scope mappings to apps/clients. A realm app has the following roles:
* manage-realm
* manage-users
* manage-applications
* manage-clients
These roles are all read/write. In the future I imagine we can add some view only roles (view-realm, view-users, view-applications, view-clients). I didn't add it this time around as it would require a fair amount of changes to admin console (everything is forms with buttons at the moment, so would have to add read only views).
When listing realms the admin console will only return the realms where the user has one or more of the above roles. The admin console will also change the menu depending on what roles the user has (for example a user that only has 'manage-clients' and 'manage-users' will not see 'settings' and 'applications').
There's a realm role called 'admin' as well. This is a composite role and when creating a new realm all roles for the new realm are added to it. Only users with this role is allowed to create, import or delete realms.
To create a new realm, with a user that has only 'manage-users' and 'manage-clients' access to this new realm, do the following:
1. Create a new realm called 'test'
2. Navigate to users for 'keycloak-admin' realm (http://localhost:8081/auth/admin/index.html#/realms/keycloak-admin/users)
3. Create new user called 'test' (enable + reset creds)
4. Click on 'Role mappings'
5. In 'Applications' drop-down select 'test-realm'
6. Select 'manage-users' and 'manage-clients' and click the right-arrow to add mapping
7. Log out of admin console, and login as 'test'
The pages in the admin console themselves haven't been disabled, only the menu to navigate there. You can try opening for example:
http://localhost:8081/auth/admin/index.html#/realms/test/social-settings
http://localhost:8081/auth/admin/index.html#/realms/test/applications
10 years, 2 months
IDToken and claims implemented
by Bill Burke
OpenID Connect IDToken and claims are implemented:
* IDToken is now added to AccessTokenResponse. I think we pass the
minimal OpenID Connect requirements now.
* You can configured allowed claims per application and oauth client.
* Allowed claims are now added to IDToken and Access Token. You can now
get the username, name, email, etc. through them. The demo
customer-portal shows this.
* I still need to add claim permission to the OAuth Grant Page.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months
Aerogear requirements
by Bill Burke
To support the initial integration between Aerogear and Keycloak, we
need to be able to handle two things:
* figure out bootstrapping on a co-bundled aerogear+keycloak zip distro,
as well as a co-bundled OpenShift cartridge.
* Be able to brand the admin console using Aerogear styles. This means
there can be no mention of "Keycloak" within login screens or within the
admin console itself. Keycloak needs to look like it is part of Aerogear.
Last thing is. We have to have a 1.0 release by June, which means we
need a major feature cut off sometime in April so we can start working
on scaling, optimization, code quality, and testing.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months
remember me/refresh token support in
by Bill Burke
* Remember me support is now in. Only works for non-social logins at
the moment though.
* admin console can now configure remember me, central login timeout,
refresh token timeout, access token timeout, and access code timeout
* Refresh token is always sent back with a grant request in the
AccessTokenResponse.
* Adapters will now check the access token's expiration on each request.
If it is stale, it will attempt to refresh it. BTW, this will fail if
the access token's roles allowed don't match the users or
application/oauth client scope anymore and the user will be redirected
back to the authentication server.
* Javascript adapter was also updated. I implemented a
onValidAccessToken(successCallback) method that will check the token,
refresh it if needed, then invoke a callback. The customer-app-js
example was updated to reflect using this callback method.
* I wrote a Javascript adapter docbook chapter and a small chapter on
what are the best practices for all the token timeout settings.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months