coverage
by Bill Burke
FYI our automated test coverage according to Intellij is +/- 50%. Some
of this is due to the fact that I didn't run coverage tests with all of
our backends.
Class, % Method, % Line, %
58.6% (403/ 688) 51.2% (3024/ 5908) 48.6% (10408/ 21422)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
logout behavior changed
by Bill Burke
I changed how logout works. It bothered me that there was no
authentication and that anybody could just push any guessed session_id
to /logout. So, it is now split up into to forms of Logout:
* GET /realms/{realm}/tokens/logout?redirect_uri={}
I removed the session_state parameter. This is a browser-based logout
and requires the user to be logged in. I still need to verify that the
redirect_uri is a valid URI.
* POST /realms/{realm}/tokens/logout
Same form parameters and authentication required as a refresh token
request. A valid refresh token is required to be able to logout the
session.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
AuthenticationProvider/Link removed
by Bill Burke
Removed everything associated with it and the authentication/ module
too. I also removed RealmModel.getLdapConfig() and representation stuff
around that. Finally, i had to disable the keycloak-picketlink-realm
project as it depended in RealmModel.getLdapConfig().
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
Re: [keycloak-dev] Postpone TOTP SPI to after 1.0.final
by Vivek Srivastav (vivsriva)
A general authentication plugin SPI for clients is what we are interested
in.
Any pointers on it, viz. which which classes should I look into would
greatly help.
Kind Regards,
Vivek
On 7/30/14, 4:53 AM, "Stian Thorgersen" <stian(a)redhat.com> wrote:
>A general authentication plugin SPI for clients should be relatively
>straightforward, not sure about users though.
>
>Credentials for users requires changes to the login flow as well as
>account management pages, so could be tricky to do it in a generic way.
>
>Worth a try though! So let's wait until after 1.0.final with the TOTP
>work.
>
>----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 29 July, 2014 10:36:50 PM
>> Subject: Re: [keycloak-dev] Postpone TOTP SPI to after 1.0.final
>>
>> By authentication plugin SPI, I actually mean a credential type plugin
>> SPI. Have a user requesting that they be able to plug in their own
>> client-cert verification mechanism.
>>
>> On 7/29/2014 5:33 PM, Bill Burke wrote:
>> > Could this TOTP SPI turn into a general authentication plugin SPI?
>>Just
>> > had an inquiry for that type of SPI.
>> >
>> > On 7/29/2014 8:51 AM, Stian Thorgersen wrote:
>> >> Due to there being quite a lot of work to do the required updates to
>> >> properly do a TOTP SPI I propose we post-pone this to 1.1.0.
>> >>
>> >> The work would include:
>> >>
>> >> * A TOTP SPI
>> >> * Account management needs to support multiple TOTPs
>> >> * Select TOTP provider to configure if required to setup TOTP on
>>login
>> >> * Select TOTP provider to use at login if user has multiple
>> >> * Configure what TOTP are permitted for a realm
>> >> * Remember TOTP option (don't ask for TOTP in 30 days on this
>>machine)
>> >> * Email implementation (send a OTP through email)
>> >> * SMS implementation (use an example SMS cloud service to send OTP)
>>- this
>> >> would also require additional fields to registration
>> >> * At least one other TOTP implementation (FreeOTP and Yubikey)
>> >> * ...
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>_______________________________________________
>keycloak-dev mailing list
>keycloak-dev(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/keycloak-dev
12 years
Remaining work for beta-4
by Stian Thorgersen
Outstanding work for beta-4:
* User federation - what's the status?
* Require SSL by default - see previous email, I think we should add this for beta-4
* Access token validation endpoint (KEYCLOAK-585)
* Rename AuditListener/Provider to EventListener/Provider (KEYCLOAK-586, KEYCLOAK-587) - should we do this?
* Support HttpServletRequest.authenticate() (KEYCLOAK-575) - should be simple enough?
* Turn off cookie cache for all http clients (KEYCLOAK-537) - not sure I understand this issue? isn't sticky sessions something that's configured by the load balancer?
* RealmModel should have a link to realm admin app (KEYCLOAK-486) - I don't think the admin console should refer to the app by name, instead it should either have a link or at least the id of the app associated with the realm
* Issue with deploying on AS7 (KEYCLOAK-572) - should be fixed with new PL release, but do we really care about supporting AS7?
Issues I propose we push to beta-5:
* LDAP sync - should this go into beta-5? or even wait until after final?
* Stress tests (KEYCLOAK-514) - we still haven't tested with a large amount of users
* DB optimizations (KEYCLOAK-515) - maybe push this to after final?
* "Transaction not active" while performing a shutdown (KEYCLOAK-470) - I can't replicate this, do we close or just set to no fix version?
* Login with totp includes password in clear text (KEYCLOAK-576) - afaik it's not good to include the password in plain-text in the html set to the client, which we do atm
Anything else?
As a reminder, I'm on PTO next week and Marek is on PTO tomorrow.
12 years
Enable SSL by default
by Stian Thorgersen
To make sure no-one goes of and uses Keycloak in production without HTTPS we should require SSL by default. To still allow developers to play with Keycloak without having to configure HTTPS first we should allow non-HTTPS if accessed via localhost only.
12 years
Sync + federation
by Marek Posolda
Hi,
at this moment I have Sync with LDAP working (one way sync for importing
LDAP users into Keycloak). I tested with ActiveDirectory and OpenDS. On
both I have paginated and also full/partial periodic sync working. Also
UserFederationProvider seems to be working with Active Directory now!
Pedro mentioned that he will do timestamped picketlink release once we
need it. So far all the LDAP related issues should be fixed, so I've
asked him for doing one. Let me know if you are aware of more issues.
The question is how to properly incorporate sync with current federation
stuff? It looks that both should work together (for example if customer
is going to write his FederationProvider to retrieve data from his DB,
he will also likely want to sync users from same DB). Also sync process
would likely need access to the federation configuration in
UserFederationProviderModel, but some configuration of Sync will be
common for all FederationProviders (For example pagination, periodic for
full/partial sync etc). So I wonder if we can add properties like this
directly into UserFederationProviderModel:
boolean enablePagination;
int pageSize;
long fullSyncPeriod; // -1 if periodic fullSync should be disabled
long partialSyncPeriod; // -1 if perodic partialSync should be disabled
And for Admin console UI, we can have some common template, which can be
added into page of particular Federation Provider. For example on
federated-ldap.html or federated-generic.html there can be checkbox on
the bottom of the page like "enable synchronization of users" and when
people check it, it will display other settings (pagination, period for
full/partial sync, button for trigger sync directly from admin console etc).
Also not sure how to properly incorporate it into UserFederationProvider
API... Actually UserFederationProvider is supposed to be per-session
component whenever Sync process may actually use more
session/transaction lifecycles. So adding methods for sync directly into
UserFederationProvider may not work though... I wonder if we can have
method on UserFederationProviderFactory:
UserSyncProvider getInstance(KeycloakSessionFactory sessionFactory,
UserFederationProviderModel model);
And UserSyncProvider being something like this:
public interface UserSyncProvider {
void syncAllUsers(KeycloakSessionFactory sessionFactory,
UserFederationProviderFactory fedFactory, String realmId,
UserFederationProviderModel fedModel)
void syncChangedUsers(KeycloakSessionFactory sessionFactory,
UserFederationProviderFactory fedFactory, String realmId,
UserFederationProviderModel fedModel, Date lastSync);
}
UserFederationProviderFactory may not be needed though as it can be
retrieved from KeycloakSessionFactory+UserFederationProviderModel, just
a convenience as UserSyncProvider will likely almost always need it. wdyt?
Note that I already have sync working with LDAP, so once we decide on
API+configuration and once we have picketlink release, I can easily
incorporate it.
Marek
12 years
