+1 for the iframe with themable AIAs. A flag maybe a good idea – at normal
conditions, AIA would use the login theme; only when "embedded" in the
account console it'd use a different theme.
It sounds to me like a good compromise.
I partially agree it should be a follow-up work. On the other hand I
wouldn't underestimate it – UX and the "impression" of the new Account
Console are IMHO important too! ;)
On Mon, Sep 2, 2019 at 10:52 PM Stian Thorgersen <sthorger(a)redhat.com>
One approach might be an iframe and a custom AIA theme for account
That way me can get it really well integrated.
On Mon, 2 Sep 2019, 13:29 Stian Thorgersen, <sthorger(a)redhat.com> wrote:
> I'm all on board with planning some followup work to polish the
> around AIA. Having a theme that matches the account console sounds like a
> decent idea. We can either make it switch the theme always for the
> console, or perhaps we could also introduce a flag to allow the client to
> control the theme and let account console use a different theme for AIAs.
> Should be noted that this should be planned as follow-up work though and
> not as part of the new account console epic. So would be most likely
> something we couldn't do until next year unless it's not to much work.
> On Wed, 28 Aug 2019 at 02:00, Stan Silvert <ssilvert(a)redhat.com> wrote:
>> On 8/27/2019 7:17 AM, Stian Thorgersen wrote:
>> > With regards to security, there's two issues. First if someone gets a
>> > of a bearer token they should not be able to hijack someones account.
>> If we
>> > allow a access token to change credentials it is very easy to
>> > hijack an account. Secondly as we're talking about an SSO solution
>> > important that an app has only access to what it needs to have access
>> > That means no applications should have direct access to users
>> > which they would need to have to be able to update through a REST API.
>> This is the point that we will need to emphasize to users when they
>> first see the new account console.
>> Vaclav is right to point out the awkwardness as it stands right now. I
>> think that we can smooth things out, but until we do, users need to
>> understand what Stian said above. Then they will at least know it is
>> for the sake of better security.
>> keycloak-dev mailing list
keycloak-dev mailing list
Senior Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.