Not able to log into admin console ufter upgrading from 1.4 -> 1.9.1
by Carsten Saathoff
Hi,
I just upgraded my old Keycloak 1.4 installation to 1.9.1. But I am not
able to log into the admin console any more. After having read the
migration guide again, it seems this could be due to the direct grant
being disabled now for some client. But to be honest, I don't quite
understand what exactly the issue is. Any ideas?
thanks and best regards
Carsten
--------------------------------------------------------------------------------------------------------------------------------------------
Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff(a)kisters.de | WWW: http://www.kisters.de
--------------------------------------------------------------------------------------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
8 years, 8 months
Limiting (network-based) access to different realms
by Guus der Kinderen
Hello,
We're working on a setup where we have two realms, a 'master' realm that we
use for administration, and another realm that is public-facing, providing
service to our end-users.
We'd like to be able to prevent access to the master realm for the general
public. We do not want, for example, to have the general public be able to
access the login page for the master realm, but we would like them to be
able to use to login page for the other realm. Things will probably get
interesting in the REST interface in that sense.
Ideally, we would expose each realm on a different network endpoint (at the
very least, use different TCP ports for each realm). We prefer to avoid a
solution that relies on URL / path-based filtering.
Can Keycloak facilitate this? Is it possible to limit exposure of a
particular realm to a specific network endpoint?
Kind regards,
Guus
8 years, 8 months
standard vs implicit flow in SPA
by Anthony Fryer
Hi,
Up until recently I automatically selected to use implicit grant flow from SPAs, but lately I've been re-assessing this since the keycloak javascript adapter provides standard flow out of the box and makes that a viable option. I also note that the keycloak admin console is a HTML5/javascript/angular js app that uses the keycloak js adapter and uses the standard flow. As a side note I find the client defaults interesting in that Implicit flow is disabled, but direct access grants are enabled (I'm coming from a mitreid connect implementation where direct access grants where disabled by default and implicit flow was enabled, so just wonder what the thinking is behind this since direct access grants are discouraged).
I'm really wondering why are you pushing standard flow from the keycloak javascript adapter instead of implicit? What are the benefits that make standard flow better in this case? One thing I have seen mentioned is refresh tokens obtained in standard flow make it easy to get a new access token, but I thought you could get refresh tokens from the implicit flow anyway, and even if not, if a user logs in with "remember me", then getting a new access token doesn't require re-entering credentials by the user. I want to make sure that when implementing keycloak in our SPA we choose the best flow and want to know if there's some reason standard flow is best.
Regards,
[Description: Description: C:\Users\jayt\Desktop\tonyjay_sig_files\virginaustralia.gif]
Anthony Fryer | Solution Architect & Designer
Mb: 0438 781 745
Email: anthony.fryer(a)virginaustralia.com<mailto:anthony.fryer@virginaustralia.com>
Virgin Australia group of airlines including Virgin Australia,
V Australia, Pacific Blue and Polynesian Blue
Please consider the environment before printing this email.
The content of this e-mail, including any attachments, is a confidential communication between Virgin Australia Airlines Pty Ltd (Virgin Australia) or its related entities (or the sender if this email is a private communication) and the intended addressee and is for the sole use of that intended addressee. If you are not the intended addressee, any use, interference with, disclosure or copying of this material is unauthorized and prohibited. If you have received this e-mail in error please contact the sender immediately and then delete the message and any attachment(s). There is no warranty that this email is error, virus or defect free. This email is also subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If this is a private communication it does not represent the views of Virgin Australia or its related entities. Please be aware that the contents of any emails sent to or from Virgin Australia or its related entities may be periodically monitored and reviewed. Virgin Australia and its related entities respect your privacy. Our privacy policy can be accessed from our website: www.virginaustralia.com
8 years, 8 months
