We need to be able to configure the truststore used by Keycloak when connecting to user federation providers, identity brokers and clients. Ideally this should be achievable through the admin console, but failing that we at least need to document how to create and configure a truststore manually.
Further we should probably also use the same truststore for database connections.
We should probably introduce a TruststoreSPI?
We are planning on removing the JPA and Mongo user session providers.
For increased durability for user sessions we highly recommend using a cluster and using a distributed cache with 2 or more owners, or using a replicated cache. We are also going to look at using persistence in Infinispan.
The reasoning behind this is that we'd like to focus on creating one really good user session provider based on Infinispan instead of maintaining multiple implementations.
Hi guys,I apologize if i am not suppose to set communication to the whole group like this.I am not able to start a thread in the key cloak forum so am trying this option.
I am new to Keycloak and trying to create a user via REST call and i am getting 401 Unauthorized error.So this what i am trying to do1. Start the Keycloak server 2. Create a realm- test-realm and assigned manag-user role to it3. Create user "test-realm-user01" and assigned all the roles i could to him.4. In my java code, i get a token and then i am trying to create a user using that token and it throws 401
Attached is the code of what i am doing.
Please let me know if i am doing anything wrong here.
(I understand that we should UI from doing all the stuff..but here i am that i want to try this out)
On 7/28/15, 12:00 AM, "keycloak-dev-bounces(a)lists.jboss.org on behalf of
Stian Thorgersen" <keycloak-dev-bounces(a)lists.jboss.org on behalf of
>----- Original Message -----
>> From: "Scott Rehorn" <srehorn(a)gmail.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 28 July, 2015 4:12:08 AM
>> Subject: [keycloak-dev] RFC: organizations
>> Hello Bill, Stian, and the rest of the keycloak-dev list from Dell
>> (software division of Dell Computers).
>> As Bill and Stian already know, our team at Dell has been integrating
>> extensions to Keycloak to build a SaaS-based identity broker, and Bill
>> Stian suggested that we run the first of our main extensions out into
>> mailing list for further discussion. Here is an overview to solicit some
>> first impressions and additional ideas in this area. We think this
>> is necessary for our own use cases, and, if it seems like a broadly
>> modification, then we can contribute the code for it.
>> Proposal: introduce a new entity called "organizations" to provide a
>> delivering specific claim values to authenticated users known in that
>> Rationale: in our group at Dell Software, we have to support the notion
>> tenancy within a single realm, but we are trying to avoid the term
>> 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
>> centralized place to store metadata for users and related client/RP
>> Example: clients A and B are SSO apps which both use KC for
>> and authorization. If a user logs into client A, he is redirected to an
>> (via Keycloak brokering) where he authenticates. After authentication,
>> 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
>> 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
>> the identity providers UX (top-level admin managed item in left menu).
>What's '/organizations' used for? If it's to view/configure organizations
>shouldn't it be contained within the admin endpoints?
My mistake - I was abbreviating implicitly :) - I actually meant that the
URL would be more like /auth/admin/organizations.
>> 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
>> but our current thinking is that the groups-everywhere approach is a
>> too general e.g., you * can * simulate relational database semantics
>> tags and selections based on combinations of tags, but when something is
>> clearly hierarchical, why not use a hierarchy? Groups would be a
>> construct could then be treated as tags to enable multiple memberships
>> much like roles are handled in KC now.
>I don't quite understand how this works. Is the following correct or not:
>* A realm has one or more organizations
>* An organization has one or more attributes (key -> value pairs)
>* A user is associated with one or more organizations
>* An IdP is associated with one or more organizations
>Then when a user logs in the attributes available would be the union of:
>* Attributes from organization associated with IdP (if IdP was used to
>* Attributes from organization associated with user
>* Attributes from user
>Further token contains attributes as configured by mappers for client.
>> Thanks for your attention and we look forward to working with you.
>> - scott r
>> keycloak-dev mailing list
>keycloak-dev mailing list
Travis build took 40+ minutes to complete in failure. I just merged in
my fixes because I think this is a problem with the build itself and not
JBoss, a division of Red Hat
We've started testing for 1.4.0 release. If everything goes smoothly I aim to release tomorrow.
Only outstanding issues are:
* KEYCLOAK-1543 reset-password-email ignores redirect_uri - can we reject this Stan?
* KEYCLOAK-1455 remove user.isTotp() usage - can we postpone to 1.5?
* KEYCLOAK-1698 Make SAML Signature CanonicalizationMethod configurable - I assume this is a minor change and will be added today? If not we should postpone to 1.5
Anything else that needs to be sorted before release? Let me know asap!
I could resolve a part of my problem and can access the admin console now but have no access to the application.
At the moment I get 2 different errors.
1. 404 - Not found
2. 403 - Forbidden (this occurred when I add "
to my web.xml file)
These errors occurred when I want to login to my application. But, before the login page loads the error occurres, so I hadn't the chance to login anyway.
I configured the following things:
1. Unziped keycloak-overlay-1.2.0.Final in Wildfly directory
2. Added keycloak extension to wildfly 8
3. Added security-domain to security subsystem
4. Added the keycloak subsystem:
5. Added security roles and security-constraints to web.xml of my application
6. Added realm, application, roles, users and user-role-mapping within the keycloak administration console
7. Deploy application + keycloak-ds.xml + auth-server.war to the wildfly 8
I hope you can help me.
as the subject says I want to secure my war files via keycloak subsystem. I use an wildfly 8 server in standalone mode and got the following configuration from the keycloak admin console (by now I configured keycloak with keycloak.json):
As in the documentation described I deleted the keycloak.json files and the part of the web.xml file where keycloak as authentication method is defined.
Now I have the problem, that keycloak seems not to be deployed. I cannot access the admin console or login to my application because of an "404 - Not found"-Error.
Any ideas what I did wrong?
PS: Excuse my English. :)
For our testsuite and for the distro, I'd like to make infinispan the
default storage as this will probably be the most used solution. This
also means we need to make sure replication is set up to be
secured/encrypted by default.
JBoss, a division of Red Hat