Re: [keycloak-dev] [wildfly-dev] Including Keycloak client adapters in WildFly 10
by Stian Thorgersen
----- Original Message -----
> From: "Jason Greene" <jason.greene(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>, wildfly-dev(a)lists.jboss.org
> Sent: Tuesday, 7 July, 2015 11:19:52 PM
> Subject: Re: [wildfly-dev] Including Keycloak client adapters in WildFly 10
>
>
> > On Jul 3, 2015, at 6:40 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
> >
> > Keycloak provides an adapter, including a WildFly extensions, to make it
> > easier to add authentication to JavaEE applications with Keycloak.
>
> Sorry for my delay replying. Comments are inline:
>
> >
> > It includes a few modules. Currently 8 Keycloak specific modules and one 1
> > third-party. The third-party is net.iharder.base64.
>
> We already have many Base64 implementations. It’s pretty easy to pull one in
> with cut and paste. Java 8 also provides one, so that could be used.
We can copy/paste it, but would it not be better to include one Base64 lib in WildFly than have everyone have their own?
>
> >
> > As the WildFly extensions includes a deployment processor that configures
> > the authentication method as well as dependencies for a deployment it's
> > easy to add authentication to a JavaEE application. All you need to do is
> > specify it in standalone.xml, for example:
> >
> > ...
> > <secure-deployment name="mywar.war”>
>
> I’m assuming that the DUPs you register match the deployment name with this
> key, and then modify the app configuration?
Yep
>
> > <realm>myrealm</realm>
> > <realm-public-key>MIIBIjAN...</realm-public-key>
> > <auth-server-url>http://localhost:8081/auth</auth-server-url>
> > <ssl-required>EXTERNAL</ssl-required>
> > <resource>mywar</resource>
> > <credential
> > name="secret">675356d8-2b6b-4602-a74f-7079e0555885</credential>
>
> You probably already did this, but such an attribute should support vault
> usage as well so that credentials can be kept out of configs.
No, pretty sure we don't, but we should
>
> > </secure-deployment>
> > ...
> >
> > I'd like to explore if we can add this extension and the required modules
> > directly to WildFly 10, rather than require users to add it themselves.
>
> Can you sync up with the elytron team? They are making other changes in this
> area, which are not yet in 10, and I want to make sure thats all compatible.
Will do, we need to have a sync with them asap in either case to make sure the Elytron SPIs cover all use-cases we need.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
10 years, 12 months
Re: [keycloak-dev] [wildfly-dev] Using feature packs for custom distributions
by Stian Thorgersen
As I see it the main issue with using core or servlets is the fact that we have to redefine modules.
Currently AFAIK when pulling in a feature pack you end up pulling in all modules for that feature pack even if you disable subsystems/extensions that rely on those modules. Would it not be better to have individual subsystems define what modules they require and only pull in the required modules for the enabled subsystems/extensions? That would allow us to build on WF full and get all module definitions from there, while still reducing the size of our distribution.
----- Original Message -----
> From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
> To: "Jason Greene" <jason.greene(a)redhat.com>
> Cc: wildfly-dev(a)lists.jboss.org, "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> Sent: Monday, 13 July, 2015 2:53:26 PM
> Subject: Re: [wildfly-dev] Using feature packs for custom distributions
>
>
> On Thu, Jul 9, 2015 at 5:13 PM, Jason Greene < jason.greene(a)redhat.com >
> wrote:
>
>
>
> > For our use-case this would also be addressed by wildfly providing a
> > feature-pack definition that’s somewhere between servlet-feature-pack and
> > full-feature-pack - as long as it contains datasources support, and jaxrs
> > support …
>
> I think this is a good idea, to skip optional deps.
>
>
> Should we add another feature pack "wildfly-web" that would be near EE web
> profile?
> We could only have feature pack without corresponding distribution.
> This would allow downstream projects like keycloak to easier build custom
> distribution using such feature pack.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
10 years, 12 months
new <kc-provider-config> directive
by Bill Burke
I added a new <kc-provider-confg> directive that can be driven by
Identity Mapper config types, Protocol Maper config types, and
Authenticator config types. Those forms now use this directive.
As part of this directive, I improved on role input. There is a new
"Role" property type. If you specify that in your property description,
a "Select Role" button appear next to the role input text box. If you
click that you get a dialog to select a role.
We can expand on the <kc-provider-config> directive in the future to add
types like 'Client', 'Certificate', 'User', etc...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 12 months
user impersonation part II
by Bill Burke
Ok, I ditched the "impersonation" client and now impersonate is done
through the admin console. There is a "Impersonate" button in the
user-list screen next to each user, then there is an Impersonate button
on the user detail page.
If the user is in the same realm as the admin, the admin is logged out
and the browser is redirected to Account.applications page.
If the user is not in the same realm as the admin, a new browser tab is
popped open and displays the Account.applications page.
I still need to do admin events for this, then I'm done.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 12 months
Custom KeycloakPrincipal in adapter
by Marcelo Arthur Sampaio
Hi,
I need to implement my custom security Principal.
What is the best way to do it in adapter for jboss eap.
Create new adapter for my business extends RefreshableKeycloakSecurityContext, KeycloakAuthenticatorValve and set the new valve class in KeycloakAdapterConfigDeploymentProcessor?
I need to set new attributes in principal and get principal in the SecurityContext.
There is an other way?
Thanks.
-
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
11 years
user impersonation committed
by Bill Burke
Taking a break from auth flows for a fe and took a first stab at user
impersonation.
Go to:
/auth/realms/{realm}/impersonate
* There's a new "impersonation" role that is in the same "client" as
view-realm, view-user, etc... roles Both in master realm apps and in
the realm-management client.
* The admin role as this "impersonation" role in its composite
* After impersonation, you are redirected to Account applications page.
"Master" impersonate service:
* If you visit the "master" impersonate service of the master realm, you
will have a list of of realms to choose from based on which
"impersonation" roles the user has assigned to him
* If you impersonate a user from "master" you are logged out and a new
user session is created as the impersonated user.
* If you impersonate a user that is within a different realm than
"master", you are not logged out of master.
Per realm impersonate service.
* If you visit the impersonate service of another realm other than
"master", you will not have a list of realms and will only be able to
impersonate a user in that realm.
* When you impersonate, you are logged out and a new user session is
created for that user.
Questions:
* I implemented this similarly to the AccountService with a new
"impersonation" client. It is a freemarker form at the moment (csrf
protected)! I'm not 100% sure I can implement it within the admin
console. Gonna look into that next.
* Would it be useful to retain this freemarker form and impersonation
client? Or should it only be available within the admin console?
* What should it look like in the admin console? Just an "impersonate"
button on the User Detail page?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
Error on add user in ldap federation
by Marcelo Arthur Sampaio
> Hi,
>
> I'm try to add user using LDAP federation, but get this error:
>
> 11:08:40,891 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak REST Interface]] (http-localhost/127.0.0.1:8080-6) JBWEB000236: Servlet.service() for servlet Keycloak REST Interface threw exception: java.lang.RuntimeException: request path: /auth/admin/realms/demo/users
> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) [keycloak-services-1.3.1.Final.jar:1.3.1.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> Caused by: java.lang.IllegalArgumentException: can't parse argument number> : cn=teste
> at java.text.MessageFormat.makeFormat(MessageFormat.java:1429) [rt.jar:1.8.0_45]
> at java.text.MessageFormat.applyPattern(MessageFormat.java:479) [rt.jar:1.8.0_45]
> at java.text.MessageFormat.<init>(MessageFormat.java:380) [rt.jar:1.8.0_45]
> at org.keycloak.services.messages.AdminMessagesProvider.getMessage(AdminMessagesProvider.java:32) [keycloak-services-1.3.1.Final.jar:1.3.1.Final]
> at org.keycloak.services.resources.ModelExceptionMapper.toResponse(ModelExceptionMapper.java:27) [keycloak-services-1.3.1.Final.jar:1.3.1.Final]
> at org.keycloak.services.resources.ModelExceptionMapper.toResponse(ModelExceptionMapper.java:17) [keycloak-services-1.3.1.Final.jar:1.3.1.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.executeExceptionMapper(SynchronousDispatcher.java:343) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:372) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:361) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.3.1.Final.jar:1.3.1.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) [keycloak-services-1.3.1.Final.jar:1.3.1.Final]
> ... 13 more
> Caused by: java.lang.NumberFormatException: For input string: > "cn=teste"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_45]
> at java.lang.Integer.parseInt(Integer.java:580) [rt.jar:1.8.0_45]
> at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_45]
> at java.text.MessageFormat.makeFormat(MessageFormat.java:1427) [rt.jar:1.8.0_45]
> ... 36 more
-
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
11 years
Packaging of ApacheDS for examples?
by Marek Posolda
I am thinking about adding LDAP example, which can be used as a base for
LDAP mappers based blog and screencast.
It will contain the application to show some claims (also both
singlevalued and multivalued attributes). It will also contain JSON
realm with UserFederation configuration pointing to our ApacheDS and
LDIF with some simple users for testing. I already added end-to-end test
to the testsuite (LDAPMultipleAttributesTest.ldapPortalEndToEndTest )
The only possible problem is how to easily bootstrap ApacheDS based LDAP
servers in user's environment. I am thinking about 3 approaches:
a) Point to the embedded ApacheDS server from our testsuite. This will
be easy to do and it's what Kerberos example is already doing . Problem
is that it requires people to checkout the keycloak sources through
github and build them through maven, so not very user friendly
b) Create docker image for ApacheDS servers (one for ldap example and
another for kerberos). Not sure if it's fine to require users to install
docker (even more pain might be on windows, when they need boot2docker
or something...)
c) Packaging with ApacheDS based servers directly into our example
package, so people can just run something like:
java -jar keycloak-examples/ldap/apacheds-embedded.jar
-Dldif.location=keycloak-examples/ldap/example.ldif
and similarly for kerberos.
For me it's easiest to go with (a) but not sure about usability...
Regarding usability (c) looks best but it's much more work.
WDYT?
Marek
11 years
Feature pack provisioning
by Marko Strukelj
Currently wildfly-server-provisioning-maven-plugin always generates a full Wildfly distribution. For Keycloak project we have three different cases of provisioning, and it would be great to be able to cover it with a common wildfly provided tool:
1) full server distribution
2) overlay distribution (unzip into existing OOTB Wildfly distribution - your problem if you use unsupported Wildfly version)
3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly.
First one is what’s currently supported, and what we use.
Second one is what we currently hack up by extracting modules directory from (1) - it would support this use case better if wildfly-server-provisioning-maven-plugin could generate 'modules only' for example.
The third one requires a CLI installer tool. I’m not aware that currently there is something for that, and we are loath to develop one from scratch.
Is it realistic to expect 2) and 3) in not so distant future?
- marko
11 years
Using feature packs for custom distributions
by Marko Strukelj
For Keycloak we’ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don’t need many of the subsystems. We’ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we’ll reconsider, but for now we don’t see much sense in basing our Keycloak distribution on servlet-feature-pack.
There are two big isues for us:
1) Big module dependency trees
Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don’t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn’t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That’s a lot just to get datasources support.
What’s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that’s how intertwined the dependencies currently are.
Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution’s disk footprint.
There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool
2) Staying in-sync with changes in full-feature-pack
Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like:
<module id=”org.jboss.as.connector” from=”full-feature-pack” include-dependencies=”true” skip-optional=”true”/>
And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync.
For our use-case this would also be addressed by wildfly providing a feature-pack definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ...
Another thing is provisioning of feature packs, which I address in another email.
- marko
11 years