Cleanup of 'Change password' screen in Account app
by Vlastimil Elias
Hi,
I have two proposals for cleanup of 'Change password' screen in Account
app based on my experience with it:
1. remove Cancel button - it has no any meaning on this screen/form, it
only reshowns form with empty fields. And also there is a bug,
"Password" field is hidden when it is used, which makes whole form unusable.
2. remove validation of current password (remove "Password" field). Two
reasons for this:
- security impact of this check is small. If attacker is able to
compromise Account app then he can always change email and then use
"Forgot password" feature to change password
- user created over Identity Provider do not know old password
(because it is not set) so he is not able to set password using this screen
After we implement support for reauthentication (KEYCLOAK-2076) then we
should set some reasonable reauth timeout for Account app instead, this
will make it more secure at all.
If you agree then I can create JIRA issue for this and provide PR.
Vlastimil
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
10 years, 10 months
Moved server bits out of integration
by Stian Thorgersen
I've moved everything server related out of integration to a separate
wildfly folder. So now integration only contains adapter related modules.
Question: should we renamed integration to adapters?
10 years, 10 months
openid-connect/login-status-iframe.html caching in browser and on CDN
by Libor Krzyzanek
Hi,
I’m wondering if it would be possible to cache all unique “.../openid-connect/login-status-iframe.html" in browser and then also on CDN e.g. Akamai.
I mean whole URL with all parameters “clinet_id” and “origin”.
This would greatly improve performance of website using JS client because Akamai servers content much faster.
I checked our instance and http header has Cache-Control:max-age=2592000 which is 30 days
Does it mean that we can configure Akamai to cache it?
When the content of iframe.html could change and thus it’s needed to be invalidated on browser cache and on CDN cache?
Thanks,
Libor Krzyžanek
jboss.org Development Team
10 years, 10 months
angular-demo-app
by replymenot
I’m trying to get the angular demo app working and I got it to work but the logout url tries to go here:
/realms/demo/tokens/logout?redirect_uri=
I’ve loaded the demo realm but it has no “tokens/logout” url
What am I doing wrong?
Greetings,
Ivo.
10 years, 10 months
user groups vs. client groups
by Adam Young
Hey guys, just catching up on the discussion. Let me share some
lessons learned from the Last four years on OpenStack Keystone working
on a very similar problem.
Keystone started off with three concepts: users, (global) roles and
tenants. A user was either an admin (based on a role) or assigned to a
tenant.
Tenants were groups of resources not managed by Keystone; Virtual
machines, disk images, and the like. All access control was managed by
the user having a token scoped to the project.
Admin was a global role...but at some point, someone decided to make it
scoped to a tenant. And things go weird. But it made sense: within a
proejct, some resources were more sensitive than others, and needed an
increased level of security. But since all of the access control policy
was written with global roles, things were actually just kind of
broken. It lead to one of the oldest bugs in Keystone, and it is still
assigned to me. I think we will have it licked this round...but that is
jumping ahead.
Keystone was written with a plugable backend approach. THe default was
Key Value stores (memcache was heavily used) but SQL was very dominant.
However, we realized that, for users, we needed to be able to pull them
out of LDAP, as most companies have large, embedded user databases, and
they want to user them, not copy them. So, projects in Openstack mapped
to groups in LDAP, and users had assignments to groups.
It was an uncomfortable fit. Tenants really were OpenStack
abstractions, and with them coming from LDAP...which was almost always
read-only, they were not editable by OpenStack resources. This was a
restriction that we dealt with for a while.
A couple new abstractions found their way into Keystone: groups (of
users) and domains. Domains were groupings for both users and tenants.
And this has continued to haunt us, because it confused two things. The
above situation with LDAP showed that the users needed to be separate
from the tenants.
Oh, and we also changed the name from tenants to projects to keep
consistent with the rest of OpenStack...want to piss off your users?
Change a key term out from underneath them...
It became clear the we needed to manage users and projects in different
ways. Users were read only from LDAP, projects were writable from
OpenStack. We split the backends along these lines: Identity manages
users, groups, and user-to-group assignments. This was due to the4
expectation that the group information from LDAP was going to be
required for managing users, which has proven to be of questionable
worth. The assignment backend held projects, roles, and role
assignments. Domains were in there as well, but it was an awkward fit,
as domains really spanned both Identity and Assignment.
We also changed how the user to projects mapping was handled: we use
role assignments for everything. Domain *owned* users, in that they
were records under the domain object, but a user got no permissions due
to being managed by a specific domain; only via role assignments.
Things really got funky when we fully integrated Federation in to
Keystone. Now, we had two abstractions for managing users: Domains and
Identity Providers. Instead of making a hard relationship between the
two...we sort of let them float.
The most hackish part is the Mapping. This is what takes the values from
the federation assertion (SAML for the most part) and maps it to
Keystone Identity objects (users and groups). While we should limit
what IdP can map to what domain, we don't. What this means is the
managing the mapping must be done by an admin, and that is a
cetrnalization I had hoped to avoid.
What do end users really need? They need a reusable set of role
assignments that span mulitple (micro)services. We are almost there,
and a few more iterations and we can get there. Keystone handles only
the core OpenStack services, but it would be much more useful if we
could open it up to the cloud in general, and make it so people could
use the Federation mapping defined in there to provide Access control to
applications running in the cloud.
Lessons learned:
Scope roles to your target abstraction from the beginning. Call this
Scoped RBAC, as opposed to what NIST does. NIST is implicitly scoped,
make KeyCLoack be explicit. Call it project, tenant, target,
application, I don't care; but a user should have a role on
*something*, otherwise you end up with namespacing inside the role
names, and a second level of mapping required.
Provide rules that allow one to explicitly assign a single role, and the
target user gets that explicit role and multiple implicit roles. The
end product is actually as set, not a tree, so just watch out for
cycles. It does not have to be a strict hierarchy, so long as it is a
Directed Acyclic Graph, you are safe.
Namespacing of roles is a client organization thing; it does not need to
end up in the roles shipped to the end application, so long as you have
a global definition of what roles mean what. Regardless, the namespace
needs to disappear when sending the assertion, or the remote side can;t
use it. So, knowing "who" you are getting an assertion for is
essential. Two different Wordpress installs mean two different role
assignments: admin on one, editor on the other.
You don't own the user database. Assume it is going to be read only.
Provide a local means to manage groups of users separate from, but on
top of, the groups that come from the federated source of Identity.
OK, that is a lot of a brain dump from someone you all don't even know.
PLease ask me questions about the details.
I'm pretty impressed with what I've seen of KeyCloak thus far. Looking
forward to getting to know it better.
10 years, 10 months
Keycloak Issue Board in JIRA
by Thomas Darimont
Hi,
the Keycloak issue overview board [1] with the 3+ lanes (Todo, In-Progress,
Done) isn't
(publicly?) available anymore since a few days.
Is there any chance to get it back? It was very helpful to keep track about
the project progress / issues.
Cheers,
Thomas
[1] https://issues.jboss.org/projects/KEYCLOAK
10 years, 10 months
Issues with Travis
by Stian Thorgersen
There's some issues with Travis and it keeps failing PRs even though the
tests pass. I'm looking at it and will update once it's resolved.
10 years, 10 months
Fixing bugs? Add tests!
by Stian Thorgersen
If you are fixing a bug please also add a test. This makes sure the issue
is actually resolved and also that we don't have a regression in the future.
10 years, 10 months
Fed up with Travis
by Stian Thorgersen
I'm fed up with Travis. Anyone have suggestions to an alternative?
My best idea now is to spin up as big an instance as we can on our public
OpenStack.
10 years, 10 months
