Admin UI
by Gabriel Cardoso
Hi guys,
here is the link for the Admin UI screens: https://gatein.mybalsamiq.com/projects/keycloak/grid. Please read the annotations in red in the pages.
- The first scenario (create the first app) goes from the screen Create first application to Overview with application. We talked about this, the concept of realm is hidden for the user here.
- The second scenario (create second application and import data from another application - aka create realm) goes from Overview with application to Overview realms application. This is important because the user still does not know that he can share info between apps. The wizard will be probably only used at this time and in the next time the user will probably want to create an application directly inside a realm.
- The third scenario (create application and link it to a realm) goes from Overview realms application to Application realm users . I guess this will not be often used, since the user already knows the concept of a realm and will probably create a new app inside it. But we should allow different task flows. Lower priority I'd say...
- The fourth scenario (create a realm and create an application in it) goes from Realm creation modal overview to Realm settings after associating app. It seems that this will be the flow for enterprise users after the second application. I guess this is the flow that Bill was thinking about.
I await comments on both the scenarios as on the flows and page details.
Thanks,
Gabriel
13 years, 1 month
Keycloak and mobile
by Matt Wringe
Thoughts on some possible ways to handle mobile aspects with Keycloak.
Its just a very brief outline of some of the options to get a
conversation started. I tried to brief as possible, but the email is
still a bit long :/
Mobile web app
Works similar to how any normal web app would work with keycloak. Only
changes really needed would be to make sure the login pages and such are
designed to work properly on varying sizes of touchscreens.
Native Mobile App Approaches
1)Native mobile app accessing keycloak through a custom webview.
Its possible for a native application to create a webview and load the
web components of keycloak through this. Requires some changes to
keycloak to return the token to the application since using a normal
redirect url isn't feasible.
For social login there are a lot of problems with this approach. Its a
custom webview, so the user will always have to enter their credentials
(which defeats the point of social login as being easy). Its also a huge
trust issues since a custom webview can easily steal credentials or
spoof the content. Facebook will be blocking logins using webviews this
fall due to the security concerns and will require using their sdk
instead, other social networks may soon follow.
2)Native mobile app accessing a native keycloak service.
A native keycloak service could be created to be run on the mobile
device which would handle account registration and login. The idea here
is that the native keycloak component would be in contact with the
keycloak server and would be managed there. This component would also
register itself as an account authenticator so that other apps can use
keycloak for authentication (in the same manner as apps do now for other
social logins).
It would use the native social sdk or system account management system
to perform social login. Once a social token is retrieve in the native
keycloak component it would be sent to the keycloak server for
verification and return a keycloak token.
Note: just to be clear, the keycloak mobile component would not be
keycloak re-written on a mobile device. Most of what happens will still
be done on the server side and it would be managed from the server's
admin console.
Thoughts on the native app approaches:
1 is a non-optimal user experience with some trust/security issues, and
already is going to be blocked by some social providers. But it requires
the least amount of native code and most things still remain on the
server side.
2 requires a lot more native code to be written and requires a lot more
changes to keycloak on the server side. But it provides a much nicer
user experience and would act the same way as current authentication
providers do to applications. There is also less issues with social
providers blocking access since we would be using the approved and
recommended methods.
Any thoughts on this? I am still catching up on keycloak so some of my
assumptions may be a bit off in a few areas.
- Matt Wringe
13 years, 1 month
What next
by Stian Thorgersen
I've finished the work on login/registration forms for SaaS and Realm. What would you like me to work on next?
One thing I thought I could do was to add registration for Realms. This should basically be adding registerPage + processRegister to TokenService. In the process I could add initialRoles to RealmModel?
13 years, 1 month
wildfly integration
by Bill Burke
I'll be working on wildfly integration the next week or so. As well as
a Resteasy release to fix some bugs that were found in filter processing
and forward() that will help us in Keycloak.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years, 1 month
credential management
by Bill Burke
Registration
* new password and password confirmation
* TOTP secret and QR generation and confirmation.
Forgot password
* Email sent to user with URL enclosed
* If required by realm, ask one or more random questions i.e.:
- What is your mother's maiden name?
- What is the last 4 digits of your social security number?
- What is the name of your first pet?
- When did you lose your virginity?
- What is your birthday?
* User enters new password and confirmation
Change Password:
* Old Password
* New Password
* Confirm new Password
Lost Authenticator
* Admin must create a temporary token and speak it to user
* User can log in with this temporary token and head to their account
management page. TOken expires after a certain amount of time.
or
* Ask one or more random questions as in Forgot password
Admin user creation:
* Email with a link is sent to user. Link prompts user for credential
set up.
* Or. Generate a temporary password that must reset by user on next
login. Temporary password is spoken to user or given to them by some
other means.
When a user logs in keycloak must check to see if
* A temporary password was created and the user must enter a new one
* Registration is incomplete and new credentials must be set up, i.e. an
authenticator.
Are there any security holes here? ONe idea I have is that the admin
would never ever see a credential. For user creation, a temporary
password is emailed to the user and never seen by the admin or the user
would have to register.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years, 1 month
SaaS login
by Stian Thorgersen
I was wondering why there are separate login/logout endpoints in SaasService? Should this not use the standard mechanism to do this (i.e. TokenService)?
13 years, 1 month
added idle processing among other things...
by Bill Burke
I added a nice jquery session timeout. You can configure it to ping a
url at various intervals to refresh things like the session cookie. It
has a nice slide down warning bar with a counting timer to warn you that
you'll be logged out. I still have a bit to do to clean it up to make
it fully functional, but you can see what it looks like.
I've also started the application creation pages. I'll have a lot more
done by the end of the week. Angular/javascript is getting more familiar.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years, 1 month
