RFC: organizations
by Scott Rehorn
Hello Bill, Stian, and the rest of the keycloak-dev list from Dell Software
(software division of Dell Computers).
As Bill and Stian already know, our team at Dell has been integrating our
own extensions to Keycloak to build a SaaS-based identity broker, and Bill
and Stian suggested that we run the first of our main extensions out into
the mailing list for further discussion. Here is an overview to solicit
some first impressions and additional ideas in this area. We think this
extension is necessary for our own use cases, and, if it seems like a
broadly useful modification, then we can contribute the code for it.
Proposal: introduce a new entity called "organizations" to provide a means
of delivering specific claim values to authenticated users known in that
organization
Rationale: in our group at Dell Software, we have to support the notion of
tenancy within a single realm, but we are trying to avoid the term ‘tenant’
as it’s too overloaded. Our typical use case is to use Keycloak+our
extensions as an external system which acts as identity broker for a
constrained set of IdPs and claims authority for users. If we use
realm-per-organization, then we wind up with a large set of repeated IdP
configurations. By introducing an entity for “organizations” then we have a
centralized place to store metadata for users and related client/RP
instances.
Example: clients A and B are SSO apps which both use KC for authentication
and authorization. If a user logs into client A, he is redirected to an IdP
(via Keycloak brokering) where he authenticates. After authentication, the
user of client A receives in his claimset additional assertions, e.g.,
subscriptionId=2057 and organizationName=CheeseCompany which are derived
from the org definition which says that the authenticated user belongs to
Cheese Company under a particular subscription. A different user in a
different organization would have a different subscription to and would
receive a different subscriptionId and organizationName.
Implementation strategy and code impact: our current implementation is
derived from the IdentityProviders model and exposes an API only at
'/organizations'. We haven’t done the UI level, but it would be similar to
the identity providers UX (top-level admin managed item in left menu).
Relationship to ‘groups’: we think that the concept of organizations is
conceptually distinct enough to treat it as a hierarchical construct. An
organization can have IdPs and users it recognizes, and such grouping of
related clients needing common assertions could be accomplished with
groups, but our current thinking is that the groups-everywhere approach is
a little too general – e.g., you **can** simulate relational database
semantics with tags and selections based on combinations of tags, but when
something is clearly hierarchical, why not use a hierarchy? Groups would be
a separate construct could then be treated as tags to enable multiple
memberships etc., much like roles are handled in KC now.
Thanks for your attention and we look forward to working with you.
- scott r
10 years, 2 months
Resolving cyclic dependency issues while implementing new SPI's
by Giriraj Sharma
Hi,
IMHO, it will be good if we move the package (org.keycloak.provider) from
keycloak-model-api to some other module which is used as a common
dependency by most other modules (like keycloak-core) .
org.keycloak.provider.* from keycloak-model-api is used by most of the
modules which implement certain Spi.
A module (X) having keycloak-model-api (Y) added as a dependency may in
turn be used by classes or other Spi's in keycloak-model-api (Y) and thus
result into a cyclic dependency.
X dependent on Y for org.keycloak.provider.* classes
Y dependent on X for X specific services/SPI's or classes
keycloak-core is used by many modules but in turn keycloak-core doesn't
uses any of keycloak-* dependency and hence will not result into any issues
like cyclic dependency. So, may be moving org.keycloak.provider.* from
keycloak-model-api to some other(like keycloak-core) will be helpful or may
be a better practice.
If this seems fine, I will be happy to make the required changes :)
Cheers,
--
Giriraj Sharma
about.me/girirajsharma
<http://about.me/girirajsharma?promo=email_sig>
Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
10 years, 2 months
Re: [keycloak-dev] Kerberos with IE does not work
by Michael Gerber
The ClearAuthenticationCache command deletes the following data:
- Session cookies
- sessionStorage
- HTTP Authentication (e.g. Digest or Basic HTTP credentials)
- HTTPS Client Certificates (e.g. sites that use certificates or SmartCards)
But keycloak needs the session cookie, otherwise the user has to relogin after each page reload.
Isn't the clientSecret anyway public if it is send in the Authorization header?
Am 29. Juli 2015 um 14:27 schrieb Bill Burke <bburke(a)redhat.com>:
The trick you found earlier doesn't work?
http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces...
Also, what if in keycloak.js if kc.clientSecret is null? Just remove
the client secret IMO. You shouldn't be exposing the client secret as
it is now public to everybody in the world....
On 7/29/2015 8:05 AM, Michael Gerber wrote:
I could find a solution for my IE problem.
IE overwrites the Authorization header in the XMLHttpRequest
(/protocol/openid-connect/token) with "Authorization: Negotiate".
To solve this problem, I added on the client the client_id
and client_secret to the form and changed the authorizeClient method, so
it checks first the form data instead of the authorization http header.
Have a look at my code:
https://github.com/gerbermichi/keycloak/commit/32880b210ed27f782a2f9fcd01...
Should I create a pull request for the changes or do you have a better
solution?
cheers
Michael
Am 22. Juli 2015 um 11:46 schrieb Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>>:
Hi Michael,
No idea if there is other solution, I've never tried SPNEGO with
Internet explorer TBH :(
Could you please create JIRA for this?
Thanks,
Marek
On 22.7.2015 10:07, Michael Gerber wrote:
Hi all
My kerberos configuration works fine with FireFox and Chrome, but it
does not work with IE.
It shows a prompt where the user has to enter a username and password.
I can successfully get an access code, but I can not get an access
token, because IE overwrites the Authorization header in the AJAX
request. (see
http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces...)
I can fix this by adding
document.execCommand('ClearAuthenticationCache', 'false');
above of
var req = new XMLHttpRequest();
approximately at the line 374 in the keycloack.js file.
Is there another solution for this problem?
cheers
Michael
_______________________________________________
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10 years, 2 months