[Android] KeyCloak Authenticator
by Summers Pittman
<tldr>DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC
AGAIN!</tldr>
Over the weekend I tried my hand at writing a Android Account
Authenticator for KeyCloak. This lets Android manage the KeyCloak
account, fetch tokens, provide tokens to other apps etc. KeyCloak
Authenticator let's you drop your keycloak.json file into an apk and
access your KeyCloak Account with one line of code from any application
on your Android device.
Right now this is very much in the "I have an itch needing scratching"
phase. It doesn't do any robust error handling, hasn't been testing off
the golden scenario, has no integration with any of the AeroGear stuff,
etc. Take a moment to watch the Demo and look at the demo project.
Video Demo :
https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
The Demo video uses Android's native account menu to request from the
authenticator a KeyCloak account. This launches the authenticator's
activity which will retrieve the credentials for Android and store
them. When I am back in the settings page and showing off the stored
account, this is all native Android UI and not part of the KeyCloak
authenticator.
When I launch the Demo application this is a separate application from
the authenticator apk. The Demo project fetches the KeyCloak account
from Android and gets its auth token. Then it makes a request to
KeyCloak's account service to fetch the user's account data.
In the demo app there are three lines of code related to auth.
final Account account = am.getAccountsByType("org.keycloak.Account")[0];
String token = am.getAuthToken(account, "org.keycloak.Account.token",
null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN);
and
provider.setDefaultHeader("Authorization", "bearer " + token);
The first two lines fetch the account and token from Android. The
second line attaches the account's auth token to the web request to the
server.
So now what? I'll probably use this for my projects/demos because it
makes my work easier. Right now it doesn't have any connection to any
of the "official" projects (Again, I wrote this over the weekend to see
if I could) however it may be quite useful to someone. In the project's
README I've included a (incomplete) list of things that don't work.
wdyt?
Links :
Project : https://github.com/secondsun/keycloak-android-authenticator
Video Demo :
https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
Demo Source :
https://github.com/secondsun/keycloak-account-authenticator-demo/
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
10 years
to use or not to use aerogear-ios-http as agerogear-ios-push dependency?
by Corinne Krych
Hello Guys
Since AGIOS-255 (Basic/Digest auth for aerogear-ios-http) is under review and will be merged soon, one question that pops up is: shall we use ag-ios-http lib to support push registration in Swift lib (aerogear-ios-push). So far we’ve been using plain NSURLSession to do it as it wasn’t yet ready on http lib.
Doing so will remove 2 lines of boiler plate code but will add a dependency (although internal to aerogear). As either ways seem fine for me, I’d like to have your views on it.
++
Corinne
10 years
Releasing new parent/bom (0.2.10)
by Daniel Passos
Hi All,
I’d like to run a new release of our parent/bom.
Here is some changes related to newer versions:
Android land
- Update Android version to the Lollipop
- Update Google Play Service to 6.1.71 (Now using aar instead of jar)
- Remove Roboeletric
- Remove Guava
- Remove Android support library
Test land
- Bump to Arquillian nondeploying container 0.2.0
- Bump to Arquillian Graphene 2.1.0.Alpha1
Feel free to test it. I have plan to release it next thursday.
The staging repo is here:
https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
— Passos
10 years