We're not talking about the admin UI at all here. This is only around the
account management and it makes no sense to expose that on a different port
as it should be accessible by end users.
With regards to KEYCLOAK-2944 and the admin console/endpoints that makes
perfect sense. Problem is that it may be very hard to implement, but we
should probably look into it at least.
On 24 March 2017 at 00:02, Thomas Connolly <thomas_connolly(a)yahoo.com>
Our scenario is that we do not want to expose the admin UI externally.This
opens the system to an external exploit.
At the moment we have two options,1) Block, via a rule on the load
balancer port / (partial) path2) Change / hack the
KeycloakSessionServletFilter to block external requests
Note we had to implement 2 as the company policies for the LB didn't allow
path based rules.The issue has been raised previously...https://issues.
Date: Thu, 23 Mar 2017 13:00:56 -0400
From: Stan Silvert <ssilvert(a)redhat.com>
Subject: Re: [keycloak-dev] New Account Management Console and Account
Content-Type: text/plain; charset=utf-8; format=flowed
On 3/23/2017 8:28 AM, Thomas Connolly wrote:
> Hi All
> Could this UI and API be put on a separate port please?
It's still very early in development, but you will probably have the
option of putting it on a different port and even a different server.
Of course, the default will be to sill run it as you do today.
But I'm interested in your use case. Why do you need it on a different
> Message: 1Date: Fri, 17 Mar 2017 08:25:47 -0700
> From: Tair Sabirgaliev <tair.sabirgaliev(a)gmail.com>
> Subject: Re: [keycloak-dev] New Account Management Console and Account
> REST api
> To: Stan Silvert <ssilvert(a)redhat.com>, stian(a)redhat.com
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Content-Type: text/plain; charset=UTF-8
> +1 for Angular2, this will make maintenance and customisation easier.
> The framework becomes very popular and close to ?JavaEE mindset?.
> On 17 March 2017 at 18:19:23, Stan Silvert (ssilvert(a)redhat.com) wrote:
> On 3/17/2017 8:09 AM, Stian Thorgersen wrote:
>> Had another idea. We could quite easily make it possible to configure
>> the "account management url" for a realm. That would let folks
>> redirect to external account management console if they want to
>> completely override it.
> That would also mean that our own account management console could be
> served from anywhere or even installed locally on the client machine.
>> On 17 March 2017 at 13:08, Stian Thorgersen <sthorger(a)redhat.com
>> <mailto:email@example.com>> wrote:
>> I'm going to call it "YetAnotherJsFramework" ;)
>> On 17 March 2017 at 12:54, Stan Silvert <ssilvert(a)redhat.com
>> <mailto:firstname.lastname@example.org>> wrote:
>> On 3/17/2017 5:47 AM, Stian Thorgersen wrote:
>>> As we've discussed a few times now the plan is to do a brand
>> new account
>>> management console. Instead of old school forms it will be
>> all modern using
>>> HTML5, AngularJS and REST endpoints.
>> One thing. That should be "Angular", not "AngularJS". Just
>> educate everyone, here is what's going on in Angular-land:
>> AngularJS is the old framework we used for the admin console.
>> Angular is the new framework we will use for the account
>> management console.
>> Most of you know the new framework as Angular2 or ng-2, but
>> the powers
>> that be want to just call it "Angular". This framework is
>> rewritten and really has no relation to AngularJS, except they
>> both come
>> from Google and both have "Angular" in the name.
>> To avoid confusion, I'm going to call it "Angualr2" for the
>>> The JIRA for this work is:
>>> We where hoping to get some help from the professional UXP
>> folks for this,
>>> but it looks like that may take some time. In the mean time
>> the plan is to
>>> base it on the following template:
>>> Also, we'll try to use some newer things from PatternFly
>> patterns to
>>> improve the screens.
>>> First pass will have the same functionality and behavior as
>> the old account
>>> management console. Second pass will be to improve the
>> usability (pages
>>> like linking, sessions and history are not very nice).
>>> We will deprecate the old FreeMarker/forms way of doing
>> things, but keep it
>>> around so it doesn't break what people are already doing.
>> This can be
>>> removed in the future (probably RHSSO 8.0?).
>>> We'll also need to provide full rest endpoints for the
>> account management
>>> console. I'll work on that, while Stan works on the UI.
>>> As the account management console will be a pure HTML5 and
>> JS app anyone
>>> can completely replace it with a theme. They can also
>> customize it a lot.
>>> We'll also need to make sure it's easy to add additional
>>> Rather than just add to AccountService I'm going to rename that
>>> to DeprecatedAccountFormService remove all REST from there
>> and add a new
>>> AccountService that only does REST. All features available
>> through forms at
>>> the moment will be available as REST API, with the exception
>> of account
>>> linking which will be done through Bills work that was
>> introduced in 3.0
>>> that allows applications to initiate the account linking.
>>> keycloak-dev mailing list
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:email@example.com>
> keycloak-dev mailing list
> keycloak-dev mailing list
keycloak-dev mailing list