social tokens?
by Bill Burke
Kabir (works at redhat) wanted to use keycloak to log in through github,
but get a token that can be used to invoke on github too. We don't have
a way to do this do we?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 9 months
JPA issue on AS 7.1.1.Final
by Stian Thorgersen
Currently master doesn't work on AS 7.1.1.Final (works on EAP 6.2/6.3 and WildFly).
The problem is that Weld tries to load the peristence-unit even though jboss.as.jpa.managed is set to false. Weld is processing the WAR as picketlink-idm-api-2.6.0.CR5.jar and picketlink-idm-simple-schema-2.6.0.CR5.jar include beans.xml. This problem was fixed in 7.1.2.Final (EAP 6.2).
On 7.1.1.Final there seems to be no way to prevent CDI from triggering as all mechanism was added later (exclude-subsystem in jboss-deployment-structure.xml or bean-discovery-mode="none" in beans.xml).
Potential solutions I've found are:
* Get rid of beans.xml in PicketLink jars
* Remove support for AS 7.1.1.Final (isn't this about time any ways?!)
9 years, 9 months
Additional things to consider for 1.0.final
by Stian Thorgersen
As we didn't have enough things to do last minute I come up with more things which I think we should do for 1.0.final:
1. Configure JPA through keycloak-server.json instead of persistence.xml
This would be super simple to do, and would let us have a single persistence.xml for everything (testsuite, server, project-integrations). Everything worthy of configuring in persistence.xml (including datasource) can be passed in the Map overrides when creating the EntityManagerFactory.
2. Introduce server-dependencies-min and server-dependencies-all poms
We have a few places that includes all the dependencies required (server, testsuite/integration and testsuite/) as well as other project such as AeroGear and LiveOak. Instead of everyone having to list all the dependencies they could have a single dependency on either server-dependencies-min or server-dependencies-all. Min would exclude most if not all provider implementations (such as PicketLink/LDAP, social providers, etc).
3. TOTP SPI
At the moment we only support Google Authenticator, I don't think that's sufficient. We should at the very least add support for one more, and have an SPI so users can add their own. I think this would be related to the UserProvider sync work, as some UserProvider implementations may require both a password and totp to verify a users credentials, while others would only be able to verify the password and then have Keycloak verify the totp.
Also, do we need to support users with more than one totp? Personally I have two for work (one I use daily and another for backup).
9 years, 9 months
more db schema changes
by Bill Burke
* created @NamedQuery for every creatQuery we have
* Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere.
names are uppercase with "_". At least 10+ years ago, this was the
standard naming convention.
* CredentialEntity now has a generated String ID. We will want to have
multiple TOTP entries in the future.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 9 months
AuthProvider refactor details
by Bill Burke
I reviewed Marek's code. The refactor is going to be pretty much
Marek's code except reorganized a little bit. Hopefully you can follow
what I'm saying. I'll try and follow up with code in a few days.
* AuthProvider is going to turn into FederationProvider which is an
extension of UserProvider
public interface FederationProvider extends UserProvider {
String getAdminPage();
Class<? extends FederatonAdmin> getAdminClass();
UserModel proxy(UserModel localUser);
}
* AuthenticationProviderManager is going to turn into a concrete class
which implements UserProvider, FederationManager. It will basically do
the same algorithm as AuthProviderManager for finding users (looping
through the realm's configured FederationProviders), except it will be
using the UserProvider interface and returning UserModels.
- UserModel getXXX() methods will search within "local" storage first
for a user.
- If exists, it will look at the UserModel.getProvider() attribute to
learn which provider to use. Then call FederationProvider.proxy()
method. This will allow the FederationProvider to proxy the UserModel
so it can perform on demand sync.
* KeycloakSession will allocate a FederationManager and wrap it with a
CacheUserProvider instead of getting the "local" user storage provider.
* LDAP/Picketlink code will turn into a set of abstract classes used to
build the LDAPFederationProvider.
- getXXX will try to locate in LDAP store. If exists, it will import
the user into the "local" storage UserModel. It will create a proxy to
this local storage. This proxy will allow on-demand sync.
Configuration:
* AuthentiationProviderModel will be renamed to FederationProviderModel.
RealmModel will also return a list of these
* LDAP code will not use Realm.getLdapConfig(). It will instead use
FederationProviderModel config.
Management:
* Federation configuration will move from the Realm Settings page, to
the Users page.
* getAdminPage and getAdminClass exist so that FederationProvider
plugins can plug-in their own admin console UI and REST API.
* FederationProvider.getAdminPage() will point to a admin console path.
When adding a FederationProvider, the admin console will load this
page for setup/config.
* The FederationProvider.getAdminClass() method will return a JAX-RS
resource locator class that implements
interface FederationAdmin {
void setAdmin(UserModel admin);
void setSession(Keycloak session);
void setRealm(RealmModel realm);
}
* The admin class will be instantiated when invoking REST calls to
.../realms/{realm}/users/providers/{provider-name}/...
That's it in a nutshell. I haven't implemented any of this, its just in
my head and there's probably a lot of details I've overlooked that I'll
figure out when I code.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 9 months
keep exploded war and add exploded themes
by Bill Burke
I want to always keep an exploded WAR. Additionally, I'd like to
explode all built-in themes in WEB-INF/classes. People are going to
want to see how its done and will need concrete examples.
For example, one of the things I want to do with Federation plugins is
that users can create their own management page for their plugin. They
will need to see examples/templates from the existing admin consoole.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 9 months
Scope param
by Stian Thorgersen
Should we add support for the scope param to 1.0.beta4? It can be done as part of the access code work.
To make it OAuth2 friendly I propose we use the following format:
?scope=realm-role1 realm-role2 app/app-role1 app2/app-role2
Basically a "list of space-delimited, case-sensitive strings" as specified in the spec, where each string is either "<realm role name>" or "<app name>/<app role name>"
9 years, 9 months
Reset password and verify email links are to long
by Stian Thorgersen
After the token manager was made stateless the full code is sent in emails (reset password and verify email), this is not very nice as it's very long.
Two ideas on how to fix this:
1. Save the code (user sessions?) and convert back to sending just the code id in the email
2. Send the info required to create a code (clientId, scope, state and redirect encoded with the realm key)
3. Send a short code that has to be copied/pasted back into the current login form
My thoughts are:
1. Nice and simple, but requires "storing" the code temporarily. Another thing we could do is to associate it with the session, this would make sure the email can only be clicked by the user that actually initiated it.
2. Not so nice as I think it'll still create too long links (especially if redirect and state are big).
3. Kinda nice, but changes the way it all works. This may actually be the optimal and more secure way to do it though.
See https://issues.jboss.org/browse/KEYCLOAK-542 for how big the link in the email actually is ;)
9 years, 9 months
