JIRA usage
by Stian Thorgersen
A few things I'd like us to follow with regards to using JIRA:
* Create a JIRA for all changes/fixes/improvements - unless they have no effect on users
* When completing an issue mark as resolved (not closed) - we'll close when we do a release (otherwise we can't change fix version without re-opening the issue)
A few things for Git:
* Try to keep it to a single commit per-JIRA
* Refer to JIRA issue in the commit message
10 years, 2 months
Session SPI for adapters
by Stian Thorgersen
Currently adapters use the HTTP session to manage sessions. This works fine for most, but I believe there's situations when something different is needed. For example for stateless applications. It also doesn't work for bearer-only applications, or oauth clients.
I propose we add a Session SPI to adapters, which allows plugging in a mechanism to manage user sessions. The interface would be something along the lines of:
* void addSession(String userId, String sessionId)
* boolean isSessionValid(String sessionId)
* boolean removeSession(String userId, String sessionId)
We could provide a few built in providers:
* HTTP Session - store in http session as we currently do
* Infinispan - store in an Infinispan cache
* JPA - store in a database
* Keycloak Session Endpoint - we could add a session info endpoint to Keycloak
* None - no session management (relies on expiration of access token to logout users)
Further, we probably need to add some option to enable/disable logout admin events for applications. For example:
* Keycloak Session Endpoint - no need to send logout events
* JPA (or Infinispan) - if multiple applications shares a session database, it's only necessary to send the logout event to one application
Thoughts?
10 years, 2 months
further changes to UserSessionModel
by Bill Burke
FYI:
To support multi-protocol logout via redirect, some changes to
UserSessionModel will need to be done. I'll need to have a "state"
variable with values like "LOGGED_IN", "LOGGING_OUT", "LOGGED_OUT". It
will also need a map to hold state relevant to the entire UserSession.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months
Database migration
by Stian Thorgersen
For 1.1.0.Beta1 the DB schema has changed (user and client sessions only). That means we'll have to provide a migration strategy. As part of testing a release we'll also have to start testing migrating a server.
I found a couple tools to help migrating databases (http://flywaydb.org/, http://www.liquibase.org/). It's probably worth looking at those as they let you have a single update script for all databases.
With that in mind, and the adapter clustering issues, 1.1.0.Beta1 is probably not going to be until later this week or early next week.
10 years, 2 months
saml basic committed
by Bill Burke
Got basic SAML POST binding working and committed with PL quickstart.
Still a lot to do:
* Don't know if it works with appliance yet. There might be some
classloader voodoo I have to overcome
* SAML logout support is next
* Get support for signatures/encryption
* Client admin console config for saml. There's a lot of metadata that
might be needed
* testsuite
Still probably a few weeks away from being done.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months
Multi-tenancy
by Frank French
Hi
I've been looking at using Keycloak to secure our cloud based apps. Everything I've tried up until now has worked like a charm (very impressed especially with the docs).
What I'm trying to do now is decide programatically which database schema to use based on the user credentials. I've had a multi-tenanted database working before so I'm not looking for help configuring that side of things. I'd like to know whether there is anything within Keycloak that I could use as a tenant identifier or whether I'm missing the point and there's a much slicker way of performing this type of operation.
Just so I'm clear I'm expecting there to be 1 Keycloak athentication database and 1 application database supporting multiple schemas.
Frank
________________________________
Causeway is committed towards reducing its carbon footprint. Please consider the environment before printing this email.
________________________________
Disclaimer Notice :-
The message and any attachments contained in this e-mail are intended for the named recipient(s) only. It may contain privileged or confidential information or information which is exempt from disclosure under the applicable laws. If you are not the intended recipient(s), you must not read, print, retain, copy distribute, forward or take any or refrain from taking any action in reliance on it or any of its attachments. If you have received or have been forwarded this e-mail in error, please notify us immediately by return e-mail or telephone (+44 (0)1628 552000) and delete this message from the computer or any other data-reading device in its entirety.
Please advise us immediately if you do not or your employer does not consent to Internet e-mail for messages of this nature.
Internet communications cannot be guaranteed to be secure and error-free as the information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender and this Company therefore do not and shall not accept any liability or responsibility of whatsoever nature in the context of this message and its attachment(s) which arises as a result of Internet transmission. Opinions, conclusion, representations, views and such other information in this message that do not relate to the official business of this Company shall be understood as neither given nor endorsed by it.
Registered Office: Comino House, Furlong Road, Bourne End, Buckinghamshire, SL8 5AQ
Registered in England No: 3921897 www.causeway.com
10 years, 2 months
