user session client association
by Bill Burke
clients are now associated with the user session in the database. The
admin console session pages have changed too to reflect this
association. Application session lists users logged in and when they
logged in. User session lists user sessions as well as the
applications/clients associated with that session. Logouts and user
logouts also use this session association whenever possible.
Apps that don't have Http Sessions (i.e. Javascript apps like th admin
console) will now show up in the session listings!
Unfortunately though, the account service does not show up in session
listings. This is because it never receives an access token/refresh
token like other apps do. I still need to change the account service so
that it shows up.
Finally, I need to update the account service session page to display
associated clients/apps. I'll do that monday.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
oauth clients and session problems
by Bill Burke
I think oauth grants are a different animal than application logins.
Applications are part of an SSO session, while oauth grants will
probably not want to be part of an SSO session. Why? If an Oauth grant
requires entering in user credentials, right now, Keycloak will create a
identity cookie. The user might not know in this situation that they
need to logout.
I was thinking that:
1. OAuth Client grant requests should always have a new session created
for them.
2. OAuth client grant requests should not ever set any cookies. Its ok
to use existing cookies for authentication though.
3. ssoSessionIdleTimeout and ssoSessionMaxLifespan should be overridable
for each oauth client and application.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
Added 'keycloak-server.json' to configure server
by Stian Thorgersen
Keycloak is now configured through keycloak-server.json (standalone/deployments/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json).
This file let's you configure:
* Model provider - including hostname/port/etc for Mongo
* Audit provider - including hostname/port/etc for Mongo
* Theme - default theme name and dir
* Scheduled - interval to run scheduled tasks
I've also added an SPI interface, which is used to detect and load SPI's. Currently the following SPI's are registered:
* ModelSpi
* AuditProviderSpi
* AuditListenerSpi
* AuthenticationSpi
* IdentityManagerSpi
* TimerSpi
There's a few 'providers' that needs to still be updated, these are themes, import/export and social.
11 years, 11 months
session idle timeout implemented
by Bill Burke
There is no more:
centralLoginLifespan
refreshTokenLifespan
Instead there is:
ssoSessionIdleTimeout
ssoSessionMaxLifespan
UserSessionModel has removed:
expires
Replaced it with:
lastSessionRefresh
The way it works is as follows. At every cookie validation or
refreshToken, the session is invalidated if the session has been idle
for a period of time, or the session has reached it's max age.
lastSessionRefresh is a timestamp which is updated at every cookie
authentication or refreshToken. For refreshToken, it is only updated if
accessCodeLifespan + lastSessionRefresh time will happen after the next
idle timeout.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
UI Polishing
by Gabriel Cardoso
I’ve just sent a pull request with changes in lots of pages, basically UI refinements.
These changes comprehend:
- Updated PatternFly to the last version
- A bunch of adjustments to make it look good with the patternfly update
- Adjusted tables to use only the patternfly code
- Update the roles selector to use patternfly buttons
- Adjusted some content (breadcrumbs, page headings)
- Adjusted the style of “required fields” and borders in many pages
- Account management area: make it look better and more like the console
I’ve tried to change the selector to use the same style as patternfly, but I didn’t manage to deal with the javascript: https://www.patternfly.org/widgets/#bootstrap-select
In my inspection, I see some usability problems:
- In the registration page, inform the required fields. In the message, inform what fields have problem instead of giving a single message “Please specify first name” each time the user hits enter.
- Modal boxes in the console don’t have explanation text.
- In the pages to define roles, when I move a role from a list to another, there is no feedback of Saved or buttons to Save / Clear. User is unaware if it was saved or not.
- In Applications > Revocation, the “not before” input is disabled and the three buttons appear: “Clear”, “Set To Now”, “Push”. Is this correct? It doesn’t make sense to me.
- In the Audit Log page, remove the links “first page”, “previous page” and “next page” when the table is empty.
- In the Add Realm page, when adding a realm, I got an error, but the realm was created.
My pull request changed lots of files, but there were no conflicts and I tested every page, so I hope to not break anything.
Thanks,
Gabriel
---
Gabriel Cardoso
User Experience Designer @ Red Hat
11 years, 11 months
1.0 Alpha 4
by Thomas Heute
Apparently the tag 1.0-alpha-4 is missing from GitHub, known issue ?
11 years, 11 months
Updated keycloak.js for session state iframe
by Stian Thorgersen
I've update keycloak.js to now create the session state iframe by default. By default it runs 'checkLoginIframe' every 5 seconds. It also runs checkLoginIframe in updateToken.
If the session is logged out clearToken is called, this will delete subject, token, etc and also invoke the onAuthLogout callback (if one is set).
The iframe can be disabled with "init({ checkLoginIframe: false })" and the interval can be set with "init({ checkLoginIframeInterval: 10 })".
I've also update the js-console and the customer-portal-js examples, and the JS documentation.
11 years, 11 months
"built-in" apps special attention
by Bill Burke
We have a bunch of built-in apps (security-admin-console, *-realm,
account, etc...) now that would be very problematic if the user edited
anything in them. I was thinking that:
- All "built-in" applications would be marked with a '*' in the listing
- All "built-in" apps would only be viewable, but not editable
I don't think any of our built in applications need to be editable,
right? I'll just add a "built-in" attribute to the application model to
implement this and a little tweak in the console.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
