9:41 a.m.
That PR will be enough for me to get by for now. We've been using .pkcs12
files and including chains at times, so not positive that 2048 is going to
be big enough. For now, I think that we'll just plan on dropping
associated cert files with the SPI libraries. Shouldn't be too bad to do
that, and maybe in the future we can look at extending that SPI to
accommodate files?
The only other note I would have is that enumerated types aren't supported
(I.E. as a dropdown with selectable values). I see where that won't be too
difficult; I'll get together a PR for selectable options. Do you want me
to file a FR for supporting file types for provider configuration?
In the end it would be really nice to have a fully extensible configuration
mechanism (in the same ways that LDAP or kerberos are configured). For
instance, LDAP configurations allow you to run validation to make sure your
authentication works. I would (ideally) like to leverage a similar
function for my federation provider. Not saying it's an essential, but
would certainly add some polish to the federation provider SPI.
Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735
On Wed, Jan 13, 2016 at 9:28 AM, Bill Burke <bburke(a)redhat.com> wrote:
I totally forgot about that PR. Are those PR changes good enough
for
you? Can you live with just that new interface? I can change and increase
the value for user federation config to 2048 to support things like
certificate pem files.
On 1/13/2016 10:18 AM, Josh Cain wrote:
Bill,
Thanks for the quick response.
I do think it would be very useful for us if the federation provider
configuration were more verbose. I saw where some work was done recently
on this (PR-1973 <https://github.com/keycloak/keycloak/pull/1973>) to
allow for better customization on labels and help texts and such.
Extending the REST endpoints for configuration could potentially be useful
as well.
We're using certificate files for a portion of our configuration, so we'd
actually need to store the file objects in the DB, as opposed to just
parsing configuration files.
Totally understand about feature freeze. Let me know what I can do to
help, I'm still getting my feet wet with Keycloak, but don't mind jumping
in when necessary.
Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735
On Wed, Jan 13, 2016 at 8:41 AM, Bill Burke <bburke(a)redhat.com> wrote:
> Right now, you're going to have to modify app.js, I can refactor app.js
> so you don't have to modify it, but, you'll have to wait until next release
> to get these changes.
>
> Unfortunately, the UserFederationProvider only supports name/value pairs
> for configuration and a max size for Value of 255 characters. I can expand
> the SPI to allow you to plug ina backend REST service that would allow you
> to parse the file and add the appropriate config, but at this time, we
> can't really provide a brand new config model for UserFederation as this is
> supposed to be feature freeze right now.
>
>
> On 1/12/2016 5:56 PM, Josh Cain wrote:
>
> Hi all,
>
> I've got a UserFederationProvider that needs 6-8 configuration elements,
> to include enumerated types and even a couple of files. I'd like to keep
> the configuration of this provider in the Keycloak admin console, but am
> not sure how to do so.
>
> I've read through the themes documentation
> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html>;,
> but I have not been able to find a suitable solution. I thought of just
> dropping a new partial in there to handle more straightforward
> configuration items like enumerated types, but couldn't find a way to do so
> without having to override the entire app.js. What's more, I was not
> certain if Keycloak was already set up to handle something like a File
> object in the REST/DB backend.
>
> I suppose my question boils down to "How can I integrate enumerated and
> file type configuration options for my UserFederationProvider into the
> Keycloak administration system?" Any help would be much appreciated -
> thanks!
>
> Josh Cain | Software Applications Engineer
> *Identity and Access Management*
> *Red Hat*
> +1 843-737-1735 <%2B1%20843-737-1735>
>
>
> _______________________________________________
> keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> 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 Hathttp://bill.burkecentral.com