10:03 p.m.
I have a prototype working and I think I've got the lay of the land.
Now I need help to make design decisions. (BTW, every time I say
WildFly I mean WildFly or EAP)
*Background*
Deployment to the /deployments directory is generally discouraged,
especially in production environments. In a domain configuration, it is
impossible because there is no deployment scanner and no /deployments
directory. Today, if you want to use the Keycloak Auth Server in a
domain, you must upload the WAR to the content repository and assign it
to one or more server groups.
This not only adds extra installation steps, it complicates management
of the auth server. The auth server could be assigned to WildFly
instances where Keycloak modules are not installed. Furthermore, WildFly
administrators with highly restricted roles in the web console and CLI
would have too much control over the auth server deployment. IMO, only
Administrator or higher should be able to control the auth server
deployment. [1]
*Subsystem-based Deployment*
The Keycloak Auth Server can instead be deployed as part of the Keycloak
Subsystem[2]. The plan is to make subsystem deployment an option on
both standalone and domain installations. This makes the Auth Server
into more of a service instead of an end-user application.
*Questions and Design Decisions*
The Auth Server WAR will live in its own module. Is there any reason
for it to be in exploded form?
The Keycloak Subsystem will get a new resource called "auth-server".
Right now I only plan to have one attribute called "enabled". By
default, this will be false in a domain environment. You don't want an
auth server to boot everywhere you install the keycloak subsystem. Do
we want this to be true for standalone? In other words, should the auth
server automatically boot if the keycloak subsystem is installed on
standalone?
Are there any other attributes to add? The Keycloak subsystem can do
anything it wants to the auth server at deployment time. It can change
context params, add modules, boot in some kind of admin-only mode, or
anything else. Configuration settings on the WAR could be made from
standalone.xml, domain.xml, CLI, etc. Anything you would like the
subsystem to do?
Do I need to allow for multiple auth server deployments in the same
WildFly instance? This is quite easy to do. For the second instance,
it would override the module name of the auth server WAR.
What are the plans and considerations for clustered auth server?
Anything I should be aware of at this point?
[1]
http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_...
[2] See "A Mixed Apporach" https://developer.jboss.org/wiki/ExtendingAS7
10:13 p.m.
On 9/16/2014 4:03 PM, Stan Silvert wrote:
*Questions and Design Decisions*
The Auth Server WAR will live in its own module. Is there any reason
for it to be in exploded form?
We have exploded form so that user can plug in their own custom user
federation providers and other plugin SPIs. These providers are scanned
for in the classpath using the META-INF/services pattern.
The Keycloak Subsystem will get a new resource called
"auth-server".
Right now I only plan to have one attribute called "enabled". By
default, this will be false in a domain environment. You don't want an
auth server to boot everywhere you install the keycloak subsystem. Do
we want this to be true for standalone? In other words, should the auth
server automatically boot if the keycloak subsystem is installed on
standalone?
Why wouldn't it boot? What is the plan for distributing Keycloak?
Are there any other attributes to add? The Keycloak subsystem can
do
anything it wants to the auth server at deployment time. It can change
context params, add modules, boot in some kind of admin-only mode, or
anything else. Configuration settings on the WAR could be made from
standalone.xml, domain.xml, CLI, etc. Anything you would like the
subsystem to do?
there is a keycloak-server.json file. Maybe that should be configurable
in the subsystem too.
Do I need to allow for multiple auth server deployments in the same
WildFly instance? This is quite easy to do. For the second instance,
it would override the module name of the auth server WAR.
I'm sure there is some weird user that will want to do this. But I
don't think this will be the norm, do you?
What are the plans and considerations for clustered auth server?
Anything I should be aware of at this point?
Might need infinispan configured for clustering going forward.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:13 a.m.
On 9/16/2014 4:13 PM, Bill Burke wrote:
On 9/16/2014 4:03 PM, Stan Silvert wrote:
> *Questions and Design Decisions*
> The Auth Server WAR will live in its own module. Is there any reason
> for it to be in exploded form?
>
We have exploded form so that user can plug in their own custom user
federation providers and other plugin SPIs. These providers are scanned
for in the classpath using the META-INF/services pattern.
They could (should?)
install the plugin as a module and expose the
services from there. But for now I'll use exploded form.
> The Keycloak Subsystem will get a new resource called "auth-server".
> Right now I only plan to have one attribute called "enabled". By
> default, this will be false in a domain environment. You don't want an
> auth server to boot everywhere you install the keycloak subsystem. Do
> we want this to be true for standalone? In other words, should the auth
> server automatically boot if the keycloak subsystem is installed on
> standalone?
>
Why wouldn't it boot? What is the plan for distributing Keycloak?
You
don't want the auth server to boot if you are just using the
subsystem for clients. But now that I think about it, I've answered my
own question. Whether or not the auth server is enabled is something
that can be defined when you add the Keycloak feature pack. So you
could set the default to whatever you want depending on the situation.
I'm not sure I understand your question about distribution. With the
feature pack, Keycloak can be added when a server is first assembled or
Keycloak can be added on later. The feature pack lives in the Maven
repo. For example, the WildFly full build will use the Keycloak FP to
add Keycloak and make it part of its download. The WildFly web build
probably won't include Keycloak, but you can use the feature pack to add
it later.
Feature Pack = module references + configuration XML + extra content
> Are there any other attributes to add? The Keycloak subsystem can do
> anything it wants to the auth server at deployment time. It can change
> context params, add modules, boot in some kind of admin-only mode, or
> anything else. Configuration settings on the WAR could be made from
> standalone.xml, domain.xml, CLI, etc. Anything you would like the
> subsystem to do?
>
there is a keycloak-server.json file. Maybe that should be configurable
in the subsystem too.
OK. I'll take a look at that. Should be very similar to
what we do for
clients configured by the subsystem.
> Do I need to allow for multiple auth server deployments in the same
> WildFly instance? This is quite easy to do. For the second instance,
> it would override the module name of the auth server WAR.
>
I'm sure there is some weird user that will want to do this. But I
don't think this will be the norm, do you?
No, not the norm. Would there be a
scenario where someone wanted to
have prod and test instances of the auth server inside the same WildFly
instance? Or maybe someone wants a single WildFly instance to host two
auth servers from unrelated entities?
> What are the plans and considerations for clustered auth server?
> Anything I should be aware of at this point?
>
Might need infinispan configured for clustering going forward.
10:03 a.m.
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 17 September, 2014 2:13:07 AM
Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
On 9/16/2014 4:13 PM, Bill Burke wrote:
>
> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>> *Questions and Design Decisions*
>> The Auth Server WAR will live in its own module. Is there any reason
>> for it to be in exploded form?
>>
> We have exploded form so that user can plug in their own custom user
> federation providers and other plugin SPIs. These providers are scanned
> for in the classpath using the META-INF/services pattern.
They could (should?) install the plugin as a module and expose the
services from there. But for now I'll use exploded form.
I don't personally like the current way we add plugins to the auth-server.war. Would
it be possible to "deploy" plugins in "deployments"? Alternatively
have plugins added as modules, then either have the Keycloak subsystem automatically
detect them on startup or require users to register them with Keycloak somehow.
>
>> The Keycloak Subsystem will get a new resource called "auth-server".
>> Right now I only plan to have one attribute called "enabled". By
>> default, this will be false in a domain environment. You don't want an
>> auth server to boot everywhere you install the keycloak subsystem. Do
>> we want this to be true for standalone? In other words, should the auth
>> server automatically boot if the keycloak subsystem is installed on
>> standalone?
>>
> Why wouldn't it boot? What is the plan for distributing Keycloak?
You don't want the auth server to boot if you are just using the
subsystem for clients. But now that I think about it, I've answered my
own question. Whether or not the auth server is enabled is something
that can be defined when you add the Keycloak feature pack. So you
could set the default to whatever you want depending on the situation.
I'm not sure I understand your question about distribution. With the
feature pack, Keycloak can be added when a server is first assembled or
Keycloak can be added on later. The feature pack lives in the Maven
repo. For example, the WildFly full build will use the Keycloak FP to
add Keycloak and make it part of its download. The WildFly web build
probably won't include Keycloak, but you can use the feature pack to add
it later.
Feature Pack = module references + configuration XML + extra content
>
>
>> Are there any other attributes to add? The Keycloak subsystem can do
>> anything it wants to the auth server at deployment time. It can change
>> context params, add modules, boot in some kind of admin-only mode, or
>> anything else. Configuration settings on the WAR could be made from
>> standalone.xml, domain.xml, CLI, etc. Anything you would like the
>> subsystem to do?
>>
>
> there is a keycloak-server.json file. Maybe that should be configurable
> in the subsystem too.
OK. I'll take a look at that. Should be very similar to what we do for
clients configured by the subsystem.
Would it not be best to drop 'keycloak-server.json' and configure it all from
standalone/domain.xml?
>
>
>> Do I need to allow for multiple auth server deployments in the same
>> WildFly instance? This is quite easy to do. For the second instance,
>> it would override the module name of the auth server WAR.
>>
> I'm sure there is some weird user that will want to do this. But I
> don't think this will be the norm, do you?
No, not the norm. Would there be a scenario where someone wanted to
have prod and test instances of the auth server inside the same WildFly
instance? Or maybe someone wants a single WildFly instance to host two
auth servers from unrelated entities?
>
>> What are the plans and considerations for clustered auth server?
>> Anything I should be aware of at this point?
>>
> Might need infinispan configured for clustering going forward.
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:23 p.m.
On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Stan Silvert" <ssilvert(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Wednesday, 17 September, 2014 2:13:07 AM
> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>
> On 9/16/2014 4:13 PM, Bill Burke wrote:
>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>> *Questions and Design Decisions*
>>> The Auth Server WAR will live in its own module. Is there any reason
>>> for it to be in exploded form?
>>>
>> We have exploded form so that user can plug in their own custom user
>> federation providers and other plugin SPIs. These providers are scanned
>> for in the classpath using the META-INF/services pattern.
> They could (should?) install the plugin as a module and expose the
> services from there. But for now I'll use exploded form.
I don't personally like the current way we add plugins to the auth-server.war. Would
it be possible to "deploy" plugins in "deployments"? Alternatively
have plugins added as modules, then either have the Keycloak subsystem automatically
detect them on startup or require users to register them with Keycloak somehow.
Anything is possible, but adding as a deployment is definitely not the
way to go. Deployments are for end-user applications.
Adding as a module is the cleanest way to do this but it requires a
little more than just copying the jar to the file system. So we're
talking about either creating a module.xml by hand or using a tool.
Since there will soon be a keycloak-auth-server module, you could put
the jar in that module and add an entry in that module.xml. That's
probably a good compromise.
>>> The Keycloak Subsystem will get a new resource called
"auth-server".
>>> Right now I only plan to have one attribute called "enabled". By
>>> default, this will be false in a domain environment. You don't want an
>>> auth server to boot everywhere you install the keycloak subsystem. Do
>>> we want this to be true for standalone? In other words, should the auth
>>> server automatically boot if the keycloak subsystem is installed on
>>> standalone?
>>>
>> Why wouldn't it boot? What is the plan for distributing Keycloak?
> You don't want the auth server to boot if you are just using the
> subsystem for clients. But now that I think about it, I've answered my
> own question. Whether or not the auth server is enabled is something
> that can be defined when you add the Keycloak feature pack. So you
> could set the default to whatever you want depending on the situation.
>
> I'm not sure I understand your question about distribution. With the
> feature pack, Keycloak can be added when a server is first assembled or
> Keycloak can be added on later. The feature pack lives in the Maven
> repo. For example, the WildFly full build will use the Keycloak FP to
> add Keycloak and make it part of its download. The WildFly web build
> probably won't include Keycloak, but you can use the feature pack to add
> it later.
>
> Feature Pack = module references + configuration XML + extra content
>>
>>> Are there any other attributes to add? The Keycloak subsystem can do
>>> anything it wants to the auth server at deployment time. It can change
>>> context params, add modules, boot in some kind of admin-only mode, or
>>> anything else. Configuration settings on the WAR could be made from
>>> standalone.xml, domain.xml, CLI, etc. Anything you would like the
>>> subsystem to do?
>>>
>> there is a keycloak-server.json file. Maybe that should be configurable
>> in the subsystem too.
> OK. I'll take a look at that. Should be very similar to what we do for
> clients configured by the subsystem.
Would it not be best to drop 'keycloak-server.json' and configure it all from
standalone/domain.xml?
For WildFly/EAP deployments, I think this will become the
preferred way
of doing it. We'll still need keycloak-server.json for other containers.
>>
>>> Do I need to allow for multiple auth server deployments in the same
>>> WildFly instance? This is quite easy to do. For the second instance,
>>> it would override the module name of the auth server WAR.
>>>
>> I'm sure there is some weird user that will want to do this. But I
>> don't think this will be the norm, do you?
> No, not the norm. Would there be a scenario where someone wanted to
> have prod and test instances of the auth server inside the same WildFly
> instance? Or maybe someone wants a single WildFly instance to host two
> auth servers from unrelated entities?
>>> What are the plans and considerations for clustered auth server?
>>> Anything I should be aware of at this point?
>>>
>> Might need infinispan configured for clustering going forward.
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2:35 p.m.
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 17 September, 2014 2:23:12 PM
Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>
>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>> *Questions and Design Decisions*
>>>> The Auth Server WAR will live in its own module. Is there any reason
>>>> for it to be in exploded form?
>>>>
>>> We have exploded form so that user can plug in their own custom user
>>> federation providers and other plugin SPIs. These providers are scanned
>>> for in the classpath using the META-INF/services pattern.
>> They could (should?) install the plugin as a module and expose the
>> services from there. But for now I'll use exploded form.
> I don't personally like the current way we add plugins to the
> auth-server.war. Would it be possible to "deploy" plugins in
> "deployments"? Alternatively have plugins added as modules, then either
> have the Keycloak subsystem automatically detect them on startup or
> require users to register them with Keycloak somehow.
Anything is possible, but adding as a deployment is definitely not the
way to go. Deployments are for end-user applications.
Plugins are end-user things though, and it certainly would make it easier to develop
plugins if you could do "mvn wildfly:deploy" ;)
Adding as a module is the cleanest way to do this but it requires a
little more than just copying the jar to the file system. So we're
talking about either creating a module.xml by hand or using a tool.
Since there will soon be a keycloak-auth-server module, you could put
the jar in that module and add an entry in that module.xml. That's
probably a good compromise.
Whatever we do we should make it simple - we've already had complaints about having to
copy a jar into standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and
updating keycloak-auth-server module.xml is even more work. Also what happens when you
upgrade the keycloak-auth-server module, wouldn't it loose the dependencies added by
users?
>
>>>> The Keycloak Subsystem will get a new resource called
"auth-server".
>>>> Right now I only plan to have one attribute called "enabled".
By
>>>> default, this will be false in a domain environment. You don't want
an
>>>> auth server to boot everywhere you install the keycloak subsystem. Do
>>>> we want this to be true for standalone? In other words, should the
auth
>>>> server automatically boot if the keycloak subsystem is installed on
>>>> standalone?
>>>>
>>> Why wouldn't it boot? What is the plan for distributing Keycloak?
>> You don't want the auth server to boot if you are just using the
>> subsystem for clients. But now that I think about it, I've answered my
>> own question. Whether or not the auth server is enabled is something
>> that can be defined when you add the Keycloak feature pack. So you
>> could set the default to whatever you want depending on the situation.
>>
>> I'm not sure I understand your question about distribution. With the
>> feature pack, Keycloak can be added when a server is first assembled or
>> Keycloak can be added on later. The feature pack lives in the Maven
>> repo. For example, the WildFly full build will use the Keycloak FP to
>> add Keycloak and make it part of its download. The WildFly web build
>> probably won't include Keycloak, but you can use the feature pack to add
>> it later.
>>
>> Feature Pack = module references + configuration XML + extra content
>>>
>>>> Are there any other attributes to add? The Keycloak subsystem can do
>>>> anything it wants to the auth server at deployment time. It can change
>>>> context params, add modules, boot in some kind of admin-only mode, or
>>>> anything else. Configuration settings on the WAR could be made from
>>>> standalone.xml, domain.xml, CLI, etc. Anything you would like the
>>>> subsystem to do?
>>>>
>>> there is a keycloak-server.json file. Maybe that should be configurable
>>> in the subsystem too.
>> OK. I'll take a look at that. Should be very similar to what we do for
>> clients configured by the subsystem.
> Would it not be best to drop 'keycloak-server.json' and configure it all
> from standalone/domain.xml?
For WildFly/EAP deployments, I think this will become the preferred way
of doing it. We'll still need keycloak-server.json for other containers.
>
>>>
>>>> Do I need to allow for multiple auth server deployments in the same
>>>> WildFly instance? This is quite easy to do. For the second instance,
>>>> it would override the module name of the auth server WAR.
>>>>
>>> I'm sure there is some weird user that will want to do this. But I
>>> don't think this will be the norm, do you?
>> No, not the norm. Would there be a scenario where someone wanted to
>> have prod and test instances of the auth server inside the same WildFly
>> instance? Or maybe someone wants a single WildFly instance to host two
>> auth servers from unrelated entities?
>>>> What are the plans and considerations for clustered auth server?
>>>> Anything I should be aware of at this point?
>>>>
>>> Might need infinispan configured for clustering going forward.
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
3:15 p.m.
On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Stan Silvert" <ssilvert(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Wednesday, 17 September, 2014 2:23:12 PM
> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>
> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>> To: keycloak-dev(a)lists.jboss.org
>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>
>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>>> *Questions and Design Decisions*
>>>>> The Auth Server WAR will live in its own module. Is there any
reason
>>>>> for it to be in exploded form?
>>>>>
>>>> We have exploded form so that user can plug in their own custom user
>>>> federation providers and other plugin SPIs. These providers are scanned
>>>> for in the classpath using the META-INF/services pattern.
>>> They could (should?) install the plugin as a module and expose the
>>> services from there. But for now I'll use exploded form.
>> I don't personally like the current way we add plugins to the
>> auth-server.war. Would it be possible to "deploy" plugins in
>> "deployments"? Alternatively have plugins added as modules, then
either
>> have the Keycloak subsystem automatically detect them on startup or
>> require users to register them with Keycloak somehow.
> Anything is possible, but adding as a deployment is definitely not the
> way to go. Deployments are for end-user applications.
Plugins are end-user things though, and it certainly would make it easier to develop
plugins if you could do "mvn wildfly:deploy" ;)
I agree. That's why
the EAP team is working on tooling for that sort of
thing. Before WildFly/AS7, everything was a deployment. But we've
changed that now to divide the world into applications and services.
> Adding as a module is the cleanest way to do this but it requires a
> little more than just copying the jar to the file system. So we're
> talking about either creating a module.xml by hand or using a tool.
>
> Since there will soon be a keycloak-auth-server module, you could put
> the jar in that module and add an entry in that module.xml. That's
> probably a good compromise.
Whatever we do we should make it simple - we've already had complaints about having
to copy a jar into standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module
and updating keycloak-auth-server module.xml is even more work. Also what happens when you
upgrade the keycloak-auth-server module, wouldn't it loose the dependencies added by
users?
If you upgrade by hand, it definitely won't lose anything. How well it
all works in the end will depend on how good the new provisioning tools
are. We can fill in the gaps with our own tools though.
If the requirement is to be able to upload the jar, we can accomplish
that one way or the other.
>>>>> The Keycloak Subsystem will get a new resource called
"auth-server".
>>>>> Right now I only plan to have one attribute called
"enabled". By
>>>>> default, this will be false in a domain environment. You don't
want an
>>>>> auth server to boot everywhere you install the keycloak subsystem.
Do
>>>>> we want this to be true for standalone? In other words, should the
auth
>>>>> server automatically boot if the keycloak subsystem is installed on
>>>>> standalone?
>>>>>
>>>> Why wouldn't it boot? What is the plan for distributing Keycloak?
>>> You don't want the auth server to boot if you are just using the
>>> subsystem for clients. But now that I think about it, I've answered my
>>> own question. Whether or not the auth server is enabled is something
>>> that can be defined when you add the Keycloak feature pack. So you
>>> could set the default to whatever you want depending on the situation.
>>>
>>> I'm not sure I understand your question about distribution. With the
>>> feature pack, Keycloak can be added when a server is first assembled or
>>> Keycloak can be added on later. The feature pack lives in the Maven
>>> repo. For example, the WildFly full build will use the Keycloak FP to
>>> add Keycloak and make it part of its download. The WildFly web build
>>> probably won't include Keycloak, but you can use the feature pack to add
>>> it later.
>>>
>>> Feature Pack = module references + configuration XML + extra content
>>>>> Are there any other attributes to add? The Keycloak subsystem can
do
>>>>> anything it wants to the auth server at deployment time. It can
change
>>>>> context params, add modules, boot in some kind of admin-only mode,
or
>>>>> anything else. Configuration settings on the WAR could be made from
>>>>> standalone.xml, domain.xml, CLI, etc. Anything you would like the
>>>>> subsystem to do?
>>>>>
>>>> there is a keycloak-server.json file. Maybe that should be configurable
>>>> in the subsystem too.
>>> OK. I'll take a look at that. Should be very similar to what we do for
>>> clients configured by the subsystem.
>> Would it not be best to drop 'keycloak-server.json' and configure it all
>> from standalone/domain.xml?
> For WildFly/EAP deployments, I think this will become the preferred way
> of doing it. We'll still need keycloak-server.json for other containers.
>>>>> Do I need to allow for multiple auth server deployments in the same
>>>>> WildFly instance? This is quite easy to do. For the second
instance,
>>>>> it would override the module name of the auth server WAR.
>>>>>
>>>> I'm sure there is some weird user that will want to do this. But I
>>>> don't think this will be the norm, do you?
>>> No, not the norm. Would there be a scenario where someone wanted to
>>> have prod and test instances of the auth server inside the same WildFly
>>> instance? Or maybe someone wants a single WildFly instance to host two
>>> auth servers from unrelated entities?
>>>>> What are the plans and considerations for clustered auth server?
>>>>> Anything I should be aware of at this point?
>>>>>
>>>> Might need infinispan configured for clustering going forward.
>>>>
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>
3:19 p.m.
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 17 September, 2014 3:15:18 PM
Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 2:23:12 PM
>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>
>> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>>> To: keycloak-dev(a)lists.jboss.org
>>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from
subsystem
>>>>
>>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>>>> *Questions and Design Decisions*
>>>>>> The Auth Server WAR will live in its own module. Is there any
reason
>>>>>> for it to be in exploded form?
>>>>>>
>>>>> We have exploded form so that user can plug in their own custom
user
>>>>> federation providers and other plugin SPIs. These providers are
>>>>> scanned
>>>>> for in the classpath using the META-INF/services pattern.
>>>> They could (should?) install the plugin as a module and expose the
>>>> services from there. But for now I'll use exploded form.
>>> I don't personally like the current way we add plugins to the
>>> auth-server.war. Would it be possible to "deploy" plugins in
>>> "deployments"? Alternatively have plugins added as modules, then
either
>>> have the Keycloak subsystem automatically detect them on startup or
>>> require users to register them with Keycloak somehow.
>> Anything is possible, but adding as a deployment is definitely not the
>> way to go. Deployments are for end-user applications.
> Plugins are end-user things though, and it certainly would make it easier
> to develop plugins if you could do "mvn wildfly:deploy" ;)
I agree. That's why the EAP team is working on tooling for that sort of
thing. Before WildFly/AS7, everything was a deployment. But we've
changed that now to divide the world into applications and services.
>
>> Adding as a module is the cleanest way to do this but it requires a
>> little more than just copying the jar to the file system. So we're
>> talking about either creating a module.xml by hand or using a tool.
>>
>> Since there will soon be a keycloak-auth-server module, you could put
>> the jar in that module and add an entry in that module.xml. That's
>> probably a good compromise.
> Whatever we do we should make it simple - we've already had complaints
> about having to copy a jar into
> standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and
> updating keycloak-auth-server module.xml is even more work. Also what
> happens when you upgrade the keycloak-auth-server module, wouldn't it
> loose the dependencies added by users?
If you upgrade by hand, it definitely won't lose anything. How well it
all works in the end will depend on how good the new provisioning tools
are. We can fill in the gaps with our own tools though.
If the requirement is to be able to upload the jar, we can accomplish
that one way or the other.
Ignoring the underlying details, it would be cool if we had a Maven plugin that could
"deploy" the plugin, maybe even restart Keycloak when a new plugin is deployed
to make sure it's available.
>
>>>>>> The Keycloak Subsystem will get a new resource called
"auth-server".
>>>>>> Right now I only plan to have one attribute called
"enabled". By
>>>>>> default, this will be false in a domain environment. You
don't want an
>>>>>> auth server to boot everywhere you install the keycloak
subsystem. Do
>>>>>> we want this to be true for standalone? In other words, should
the
>>>>>> auth
>>>>>> server automatically boot if the keycloak subsystem is installed
on
>>>>>> standalone?
>>>>>>
>>>>> Why wouldn't it boot? What is the plan for distributing
Keycloak?
>>>> You don't want the auth server to boot if you are just using the
>>>> subsystem for clients. But now that I think about it, I've answered
my
>>>> own question. Whether or not the auth server is enabled is something
>>>> that can be defined when you add the Keycloak feature pack. So you
>>>> could set the default to whatever you want depending on the situation.
>>>>
>>>> I'm not sure I understand your question about distribution. With
the
>>>> feature pack, Keycloak can be added when a server is first assembled or
>>>> Keycloak can be added on later. The feature pack lives in the Maven
>>>> repo. For example, the WildFly full build will use the Keycloak FP to
>>>> add Keycloak and make it part of its download. The WildFly web build
>>>> probably won't include Keycloak, but you can use the feature pack to
add
>>>> it later.
>>>>
>>>> Feature Pack = module references + configuration XML + extra content
>>>>>> Are there any other attributes to add? The Keycloak subsystem
can do
>>>>>> anything it wants to the auth server at deployment time. It
can
>>>>>> change
>>>>>> context params, add modules, boot in some kind of admin-only
mode, or
>>>>>> anything else. Configuration settings on the WAR could be made
from
>>>>>> standalone.xml, domain.xml, CLI, etc. Anything you would like
the
>>>>>> subsystem to do?
>>>>>>
>>>>> there is a keycloak-server.json file. Maybe that should be
>>>>> configurable
>>>>> in the subsystem too.
>>>> OK. I'll take a look at that. Should be very similar to what we do
for
>>>> clients configured by the subsystem.
>>> Would it not be best to drop 'keycloak-server.json' and configure it
all
>>> from standalone/domain.xml?
>> For WildFly/EAP deployments, I think this will become the preferred way
>> of doing it. We'll still need keycloak-server.json for other containers.
>>>>>> Do I need to allow for multiple auth server deployments in the
same
>>>>>> WildFly instance? This is quite easy to do. For the second
instance,
>>>>>> it would override the module name of the auth server WAR.
>>>>>>
>>>>> I'm sure there is some weird user that will want to do this.
But I
>>>>> don't think this will be the norm, do you?
>>>> No, not the norm. Would there be a scenario where someone wanted to
>>>> have prod and test instances of the auth server inside the same WildFly
>>>> instance? Or maybe someone wants a single WildFly instance to host two
>>>> auth servers from unrelated entities?
>>>>>> What are the plans and considerations for clustered auth
server?
>>>>>> Anything I should be aware of at this point?
>>>>>>
>>>>> Might need infinispan configured for clustering going forward.
>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>
3:59 p.m.
This conversation has become hard to follow. Can you guys summarize
what you've agreed to?
On 9/17/2014 9:19 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Stan Silvert" <ssilvert(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Wednesday, 17 September, 2014 3:15:18 PM
> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>
> On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: keycloak-dev(a)lists.jboss.org
>>> Sent: Wednesday, 17 September, 2014 2:23:12 PM
>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>
>>> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from
subsystem
>>>>>
>>>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>>>>> *Questions and Design Decisions*
>>>>>>> The Auth Server WAR will live in its own module. Is there
any reason
>>>>>>> for it to be in exploded form?
>>>>>>>
>>>>>> We have exploded form so that user can plug in their own custom
user
>>>>>> federation providers and other plugin SPIs. These providers are
>>>>>> scanned
>>>>>> for in the classpath using the META-INF/services pattern.
>>>>> They could (should?) install the plugin as a module and expose the
>>>>> services from there. But for now I'll use exploded form.
>>>> I don't personally like the current way we add plugins to the
>>>> auth-server.war. Would it be possible to "deploy" plugins in
>>>> "deployments"? Alternatively have plugins added as modules,
then either
>>>> have the Keycloak subsystem automatically detect them on startup or
>>>> require users to register them with Keycloak somehow.
>>> Anything is possible, but adding as a deployment is definitely not the
>>> way to go. Deployments are for end-user applications.
>> Plugins are end-user things though, and it certainly would make it easier
>> to develop plugins if you could do "mvn wildfly:deploy" ;)
> I agree. That's why the EAP team is working on tooling for that sort of
> thing. Before WildFly/AS7, everything was a deployment. But we've
> changed that now to divide the world into applications and services.
>>
>>> Adding as a module is the cleanest way to do this but it requires a
>>> little more than just copying the jar to the file system. So we're
>>> talking about either creating a module.xml by hand or using a tool.
>>>
>>> Since there will soon be a keycloak-auth-server module, you could put
>>> the jar in that module and add an entry in that module.xml. That's
>>> probably a good compromise.
>> Whatever we do we should make it simple - we've already had complaints
>> about having to copy a jar into
>> standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and
>> updating keycloak-auth-server module.xml is even more work. Also what
>> happens when you upgrade the keycloak-auth-server module, wouldn't it
>> loose the dependencies added by users?
> If you upgrade by hand, it definitely won't lose anything. How well it
> all works in the end will depend on how good the new provisioning tools
> are. We can fill in the gaps with our own tools though.
>
> If the requirement is to be able to upload the jar, we can accomplish
> that one way or the other.
Ignoring the underlying details, it would be cool if we had a Maven plugin that could
"deploy" the plugin, maybe even restart Keycloak when a new plugin is deployed
to make sure it's available.
>>
>>>>>>> The Keycloak Subsystem will get a new resource called
"auth-server".
>>>>>>> Right now I only plan to have one attribute called
"enabled". By
>>>>>>> default, this will be false in a domain environment. You
don't want an
>>>>>>> auth server to boot everywhere you install the keycloak
subsystem. Do
>>>>>>> we want this to be true for standalone? In other words,
should the
>>>>>>> auth
>>>>>>> server automatically boot if the keycloak subsystem is
installed on
>>>>>>> standalone?
>>>>>>>
>>>>>> Why wouldn't it boot? What is the plan for distributing
Keycloak?
>>>>> You don't want the auth server to boot if you are just using the
>>>>> subsystem for clients. But now that I think about it, I've
answered my
>>>>> own question. Whether or not the auth server is enabled is
something
>>>>> that can be defined when you add the Keycloak feature pack. So you
>>>>> could set the default to whatever you want depending on the
situation.
>>>>>
>>>>> I'm not sure I understand your question about distribution. With
the
>>>>> feature pack, Keycloak can be added when a server is first assembled
or
>>>>> Keycloak can be added on later. The feature pack lives in the Maven
>>>>> repo. For example, the WildFly full build will use the Keycloak FP
to
>>>>> add Keycloak and make it part of its download. The WildFly web
build
>>>>> probably won't include Keycloak, but you can use the feature pack
to add
>>>>> it later.
>>>>>
>>>>> Feature Pack = module references + configuration XML + extra content
>>>>>>> Are there any other attributes to add? The Keycloak
subsystem can do
>>>>>>> anything it wants to the auth server at deployment time. It
can
>>>>>>> change
>>>>>>> context params, add modules, boot in some kind of admin-only
mode, or
>>>>>>> anything else. Configuration settings on the WAR could be
made from
>>>>>>> standalone.xml, domain.xml, CLI, etc. Anything you would
like the
>>>>>>> subsystem to do?
>>>>>>>
>>>>>> there is a keycloak-server.json file. Maybe that should be
>>>>>> configurable
>>>>>> in the subsystem too.
>>>>> OK. I'll take a look at that. Should be very similar to what we
do for
>>>>> clients configured by the subsystem.
>>>> Would it not be best to drop 'keycloak-server.json' and configure
it all
>>>> from standalone/domain.xml?
>>> For WildFly/EAP deployments, I think this will become the preferred way
>>> of doing it. We'll still need keycloak-server.json for other
containers.
>>>>>>> Do I need to allow for multiple auth server deployments in
the same
>>>>>>> WildFly instance? This is quite easy to do. For the second
instance,
>>>>>>> it would override the module name of the auth server WAR.
>>>>>>>
>>>>>> I'm sure there is some weird user that will want to do this.
But I
>>>>>> don't think this will be the norm, do you?
>>>>> No, not the norm. Would there be a scenario where someone wanted to
>>>>> have prod and test instances of the auth server inside the same
WildFly
>>>>> instance? Or maybe someone wants a single WildFly instance to host
two
>>>>> auth servers from unrelated entities?
>>>>>>> What are the plans and considerations for clustered auth
server?
>>>>>>> Anything I should be aware of at this point?
>>>>>>>
>>>>>> Might need infinispan configured for clustering going forward.
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>
>
>
_______________________________________________
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 Hat
http://bill.burkecentral.com
7:15 p.m.
On 9/17/2014 9:59 AM, Bill Burke wrote:
This conversation has become hard to follow. Can you guys summarize
what you've agreed to?
I think I got my questions answered. We veered into a
discussion about
how to deal with plugins.
The auth server will live in its own module and be deployed by the
Keycloak subsystem.
Here are the options for dealing with plugins that use the
META-INF/services pattern:
1) Leave the WAR as exploded. So it's the same as today except you
drop your jar in the WAR in the module instead of the WAR in the
/deployments directory.
2) Put the jar in its own module and reference it from the Keycloak
subsystem
3) Put the jar in the same module as the auth server and add a line in
module.xml for it.
4) Use a tool to accomplish one of the first three.
I think that #1 and #3 will require no additional code. So for the sake
of getting this out sooner, we might want to pick one of those for the
time being.
On 9/17/2014 9:19 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 3:15:18 PM
>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>
>> On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>> Sent: Wednesday, 17 September, 2014 2:23:12 PM
>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>>
>>>> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>>>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from
subsystem
>>>>>>
>>>>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>>>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>>>>>> *Questions and Design Decisions*
>>>>>>>> The Auth Server WAR will live in its own module. Is
there any reason
>>>>>>>> for it to be in exploded form?
>>>>>>>>
>>>>>>> We have exploded form so that user can plug in their own
custom user
>>>>>>> federation providers and other plugin SPIs. These providers
are
>>>>>>> scanned
>>>>>>> for in the classpath using the META-INF/services pattern.
>>>>>> They could (should?) install the plugin as a module and expose
the
>>>>>> services from there. But for now I'll use exploded form.
>>>>> I don't personally like the current way we add plugins to the
>>>>> auth-server.war. Would it be possible to "deploy" plugins
in
>>>>> "deployments"? Alternatively have plugins added as modules,
then either
>>>>> have the Keycloak subsystem automatically detect them on startup or
>>>>> require users to register them with Keycloak somehow.
>>>> Anything is possible, but adding as a deployment is definitely not the
>>>> way to go. Deployments are for end-user applications.
>>> Plugins are end-user things though, and it certainly would make it easier
>>> to develop plugins if you could do "mvn wildfly:deploy" ;)
>> I agree. That's why the EAP team is working on tooling for that sort of
>> thing. Before WildFly/AS7, everything was a deployment. But we've
>> changed that now to divide the world into applications and services.
>>>> Adding as a module is the cleanest way to do this but it requires a
>>>> little more than just copying the jar to the file system. So we're
>>>> talking about either creating a module.xml by hand or using a tool.
>>>>
>>>> Since there will soon be a keycloak-auth-server module, you could put
>>>> the jar in that module and add an entry in that module.xml. That's
>>>> probably a good compromise.
>>> Whatever we do we should make it simple - we've already had complaints
>>> about having to copy a jar into
>>> standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and
>>> updating keycloak-auth-server module.xml is even more work. Also what
>>> happens when you upgrade the keycloak-auth-server module, wouldn't it
>>> loose the dependencies added by users?
>> If you upgrade by hand, it definitely won't lose anything. How well it
>> all works in the end will depend on how good the new provisioning tools
>> are. We can fill in the gaps with our own tools though.
>>
>> If the requirement is to be able to upload the jar, we can accomplish
>> that one way or the other.
> Ignoring the underlying details, it would be cool if we had a Maven plugin that could
"deploy" the plugin, maybe even restart Keycloak when a new plugin is deployed
to make sure it's available.
>
>>>>>>>> The Keycloak Subsystem will get a new resource called
"auth-server".
>>>>>>>> Right now I only plan to have one attribute called
"enabled". By
>>>>>>>> default, this will be false in a domain environment. You
don't want an
>>>>>>>> auth server to boot everywhere you install the keycloak
subsystem. Do
>>>>>>>> we want this to be true for standalone? In other words,
should the
>>>>>>>> auth
>>>>>>>> server automatically boot if the keycloak subsystem is
installed on
>>>>>>>> standalone?
>>>>>>>>
>>>>>>> Why wouldn't it boot? What is the plan for distributing
Keycloak?
>>>>>> You don't want the auth server to boot if you are just using
the
>>>>>> subsystem for clients. But now that I think about it, I've
answered my
>>>>>> own question. Whether or not the auth server is enabled is
something
>>>>>> that can be defined when you add the Keycloak feature pack. So
you
>>>>>> could set the default to whatever you want depending on the
situation.
>>>>>>
>>>>>> I'm not sure I understand your question about distribution.
With the
>>>>>> feature pack, Keycloak can be added when a server is first
assembled or
>>>>>> Keycloak can be added on later. The feature pack lives in the
Maven
>>>>>> repo. For example, the WildFly full build will use the Keycloak
FP to
>>>>>> add Keycloak and make it part of its download. The WildFly web
build
>>>>>> probably won't include Keycloak, but you can use the feature
pack to add
>>>>>> it later.
>>>>>>
>>>>>> Feature Pack = module references + configuration XML + extra
content
>>>>>>>> Are there any other attributes to add? The Keycloak
subsystem can do
>>>>>>>> anything it wants to the auth server at deployment time.
It can
>>>>>>>> change
>>>>>>>> context params, add modules, boot in some kind of
admin-only mode, or
>>>>>>>> anything else. Configuration settings on the WAR could
be made from
>>>>>>>> standalone.xml, domain.xml, CLI, etc. Anything you would
like the
>>>>>>>> subsystem to do?
>>>>>>>>
>>>>>>> there is a keycloak-server.json file. Maybe that should be
>>>>>>> configurable
>>>>>>> in the subsystem too.
>>>>>> OK. I'll take a look at that. Should be very similar to
what we do for
>>>>>> clients configured by the subsystem.
>>>>> Would it not be best to drop 'keycloak-server.json' and
configure it all
>>>>> from standalone/domain.xml?
>>>> For WildFly/EAP deployments, I think this will become the preferred way
>>>> of doing it. We'll still need keycloak-server.json for other
containers.
>>>>>>>> Do I need to allow for multiple auth server deployments
in the same
>>>>>>>> WildFly instance? This is quite easy to do. For the
second instance,
>>>>>>>> it would override the module name of the auth server
WAR.
>>>>>>>>
>>>>>>> I'm sure there is some weird user that will want to do
this. But I
>>>>>>> don't think this will be the norm, do you?
>>>>>> No, not the norm. Would there be a scenario where someone wanted
to
>>>>>> have prod and test instances of the auth server inside the same
WildFly
>>>>>> instance? Or maybe someone wants a single WildFly instance to
host two
>>>>>> auth servers from unrelated entities?
>>>>>>>> What are the plans and considerations for clustered auth
server?
>>>>>>>> Anything I should be aware of at this point?
>>>>>>>>
>>>>>>> Might need infinispan configured for clustering going
forward.
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
3786
days inactive
3787
days old
9 comments
3 participants
participants (3)
-
Bill Burke -
Stan Silvert -
Stian Thorgersen