[keycloak-dev] Few Questions on usage
bburke at redhat.com
Mon May 21 09:56:51 EDT 2018
keycloak really isn't designed as a SaaS where different companies
share the same instance and datastore. We almost went that route, but
decided that with docker and openshift and containers and all, much
better to "sandbox" the whole server.
On Mon, May 21, 2018 at 9:35 AM, Anil Saldanha <asaldanha1947 at gmail.com> wrote:
> Bill - while I see the benefits of dynamic scripting in authentication flows, I wonder if it opens a can of worms in terms of security holes. How do you sandbox scripts?
> What do you think ?
>> On May 21, 2018, at 8:21 AM, Bill Burke <bburke at redhat.com> wrote:
>>> On Mon, May 21, 2018 at 9:00 AM, gambol <gambol99 at gmail.com> wrote:
>>> Apologizes for the wide range questions .. but figured a number for be
>>> useful for the user base.
>>> - Using the current scripted authentication in Authentication Flows would
>>> it possible to use script to say if clientid == x and user have role x,
>>> permitted else not. Also do you have a repo with some examples of scripts?
>>> similar to https://github.com/auth0/rules
>> Yes, you could do that. No repo, sorry. This was a community
>> contribution and we don't have much more than basic docs.
>>> - Will the scripting always be global level, or is there any plan to make
>>> it per client? or perhaps a better question would be will authentication
>>> flow always be at the realm level.
>> You can assign a specific authentiction flow to a specific client, but
>> we do not have anything like "step up" authentication yet.
>>> - Assuming a realm with multiple identity providers, is there any means by
>>> which a client and enforce that a use came in via a specific identity
>>> provider? or if i come in via provider x they need to use MFA (would this
>>> be done with a Post Login Flow on the provider perhaps?).
>> That might work, but post login flow was implemented mainly to resolve
>> import from external provider.
>>> - Is the any plans to make Groups per client and under the client ui? as
>>> for realms which have many disassociated applications but common user bases
>>> it makes it easier for them to manage.
>> You are the first to ask, but we should do something similar to what
>> was done for roles.
>>> - Are the any plans to expose metrics (or perhaps they are already
>>> exposed)? via jmx, stats, prometheus etc .. around logins, successful,
>>> failed etc, any latency measures on identity providers, infinispan /
>>> database operations etc
>> Something that should be scheduled. We have audit logs for all
>> different types of events, but I'm pretty sure we don't tabulate any
>> of it. We have basic generic metrics that any "application server"
>> would provide through Wildfly.
>>> - Is there any way to turn off the internal passwords and force via
>>> identity provider? .. i guess this is where scripting becomes useful .. i.e
>>> if client = y get the provider name and deny if not y etc
>> Elaborate? Not sure what you mean.Not understanding this one.
>> Bill Burke
>> Red Hat
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
More information about the keycloak-dev