Future direction of PicketLink SAML capabilities post-merge
by jboss.atomicknight＠xoxy.net
Hi there,
I'm writing with regard to the announcement about PicketLink merging into
Keycloak, particularly as it pertains to the SAML capabilities and APIs
currently offered by PicketLink today.
>From what I understand, the focus of Keycloak has historically been to
provide a standalone application/appliance that runs "out of process"
relative to an application utilizing those capabilities. In contrast,
PicketLink has been focused on lower-level APIs that are intended to be
integrated "in process" relative to the application. Is this understanding
correct? If so, will the combined project continue to support both
approaches?
More specifically, my company has developed an application that relies on
PicketLink's SAML APIs to provide SAML support as part of a larger security
subsystem. This uses the SPFilter class and the associated SAML2Handler
classes to handle SAML messages, but adapts the inputs/outputs to plug into
the existing security infrastructure (not built using PicketLink). Going
forward, will these parts of the merged codebase still be supported as
first class Java APIs? Or will they be replaced by web service APIs or
other equivalent endpoints?
Thanks in advance for your help.
-Abraham
9 years, 1 month
Deploy theme as module and simplified creating theme for embedding
by Stian Thorgersen
I've introduce the concept of a theme packaged as a JAR. This makes it possible to deploy a theme as a module (which is nice for domain mode) and simplifies creating themes when KC is embedded into other projects.
A theme JAR consists of:
* META-INF/keycloak-themes.json A description of what themes are included in the jar
* theme/<theme type>/<theme name> Templates, resources, etc as before
Basically there's no longer any need to implement your own theme provider just to bundle a theme as a jar :)
While doing this I realised that the structure of:
* <theme type>/<theme name>
Is wrong! It should be:
* <theme name>/<theme type>
Anyone have an objection to changing that? The reasoning is that it will be common to create a theme of different variants and having the theme name as the root makes it easier to copy to standalone/configuration/themes as well as groups everything for a theme into one place.
9 years, 1 month
Importing json from 1.1.0 into 1.2.0
by Stian Thorgersen
I came up with a simple solution to import json from 1.1.0 to 1.2.0.
In RealmRepresentation and UserRepresentation the old social properties are re-added with a @Deprecated. In RepresentationToModel the first thing that's done is to convert these to the new identity brokering properties. For details see https://github.com/keycloak/keycloak/commit/8a38597b3acdb568d794d1d424961...
If we do the same for claims to protocol-mappers we should be fine with importing json representations from 1.1.0.Final into 1.2.0.Beta1.
9 years, 1 month
Social login with user registration disabled
by Leonardo Loch Zanivan
I have a requirement in a SaaS application to disable user registration, so
only administrators can register new users.
Users should be able to login with social providers such as Google+ and
Facebook. To allow this, each user could link in his profile.
However, when I enable social login, new users are registred automatically
to the realm. I don't think that right, since User Registration is
disabled.
:/
9 years, 1 month
Still some broker work to do
by Bill Burke
There's still some broker work to do before release. There's one or
more blocker bugs and logout doesn't work. The UI is quirky and there
is some redundant metadata.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 1 month
Issue with latest Github master and SAML IDP providers?
by Guy Davis
Good day,
I've been using a sample Picketlink IDP locally for testing the SAML v2.0
ID brokering, however after updating to latest master and re-deploying
components, I'm getting the following error. Any tips?
[image: Inline image 1]
Thanks in advance,
Guy
9 years, 1 month
need to release 1.2.beta1
by Bill Burke
We need to release beta1 next week. A few users are either working from
master, asking for a release, and/or bugging us about an unworking
master. Let's finish up jiras or defer them please so we can release
next week.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 1 month
Introducing KeycloakContext
by Stian Thorgersen
Currently we pass a lot of things around. For example:
AuthenticationManager.logout(session, realm, userSession, uriInfo, connection)
Flows.forms(session, realm, client, uriInfo)
I propose we introduce a KeycloakContext that can hold everything. It would be injectable by RestEasy:
@Context
KeycloakContext context;
And would look something like:
public interface KeycloakContext {
KeycloakSession session();
RealmModel realm();
HttpRequest request();
UriInfo uriInfo();
ClientConnection clientConnection();
EventBuilder event();
}
Also, I think we should convert AuthenticationManager and TokenManager into providers so they can be obtained from the session rather than passing it around everywhere.
The above changes would be introduced after 1.2.0.Beta1 and can be done incrementally!!
9 years, 1 month
Improvements of registration over Social Login providers
by Vlastimil Elias
Hi great Keycloak dev team,
during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 I
found few things which should be improved in area of registration over
Social Login providers.
I'd like to discuss them here before creating JIRAs. I believe I should
implement these changes if you will be interested.
1. It is not possible to disable registration over Social provider
======================================
Once provider is created then it is always possible to register over it,
even if "User registration" is disabled in realm "Login Settings". I
think it should be possible to disable social registrations and allow
only to link social logins to existing accounts (eg. loaded from other
system).
Marek Posolda pointed me to
https://issues.jboss.org/browse/KEYCLOAK-1036 which is rejected without
any comment. I understand that this global setting is probably not a
good solution, so my proposal is to add independent "User registration"
switch into configuration of each Identity provider, so admin will get
fine grained control.
2. Username from Social provider is used as Keycloak username during
registration
===================================================
This can lead to the situation that user registering eg. over Twitter
will not be able to register as other user eg. from Facebook will use
same username there and occupy it in Keycloak as first.
My proposal is to extend configuration of each Identity provider by new
option "Username type" which will be select from these options:
* provided username exact - works as now, username is got from
provider, user can't register if occupied in KC already
* provided username unique - KC will take username from provider, if
occupied then it adds some random number to it to create unique
username and allow user to register
* provided email - this is related to KEYCLOAK-1074, I need this
option for my project. I know that email is not provided by some
providers (eg Twitter) so I can't use them until KEYCLOAK-1053 is
resolved somehow
So let me know what you think about my proposals, can I implement them?
Cheers
Vlastimil
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
9 years, 1 month
Keycloak-Initial configuration
by Prakhash siva
Hi all, I'm Prakhash From Sri Lanka. I'm willing to contribute keycloak. I
have cloned the keycloak repository but I could not figure out the initial
configurations I need to do. I was able to find many tutorials saying how
to configure keycloak with specific application but I believe it is not for
keycloak development as a contributor. So can you please help me to do the
initial configurations. I'm using ubuntu
Thanks
--
*Sivakumar Prakhash*
*Undergraduate*
*Computer Science & Engineering*
*University of Moratuwa.*
9 years, 1 month
