[Keycloak][Get identity provides roles]
by Salvatore Incandela
Hi guys, is possible to populate user roles given by an identity provider
(another keycloak instance) getting those from the json claim?
--
Salvatore Incandela
Middleware Consultant
------------------------------
Red Hat - www.redhat.com
Via Andrea Doria 41M
00192 Roma (Italy)
Mobile +39 349 6196615 <+39%20349%20619%206615>
Fax +39 06 39728535 <+39%2006%203972%208535>
E-mail salvatore.incandela(a)redhat.com
7 years, 9 months
Re: [keycloak-user] IDP Initiated Login
by John D. Ament
Ok, I must have fat fingered there at the end. Sorry.
With that said, assuming that I want IDP initiated login, it seems like
what I have to do is:
- Create a SAML client in Keycloak for my application.
- Follow the IDP initiated flow from
https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/cl...
- Point my IDP to the endpoint that gets generated in here.
As a result, it seems like I don't have to even create a SAML IDP in
Keycloak, unless that somehow gets used for SP initiated.
John
On Wed, Feb 22, 2017 at 10:15 PM John D. Ament <john.d.ament(a)gmail.com>
wrote:
> This is the part that's confusing me. What do you mean by a "URL
> somewhere that links to your app which will then redirect to keycloak"?
>
> Are you talking about triggering the inbound IDP initiated by first
> calling into my app?
>
> If I look at (Okta for instance) they actually have a portal-like site
> that users can leverage to directly link to their apps. The links
> generated here are doing IDP initiated SSO, by triggering SAML in the
> broker then the broker is expected to forward to the client (and mind you,
> I know very little about SAML, but this is how I'm seeing it behave in the
> browser).
>
> With that said, assum
>
>
> On Wed, Feb 22, 2017 at 9:50 PM Bill Burke <bburke(a)redhat.com> wrote:
>
> OIDC/OAuth doesn't have an IDP initiated protocol. You'll have to
> create a URL somewhere that links to your app which will then redirect
> to Keycloak.
>
>
> On 2/22/17 8:23 PM, John D. Ament wrote:
> > Looks like I answered half of my question -
> > https://issues.jboss.org/browse/KEYCLOAK-4454
> >
> > Seems like it will only work if I'm using SAML.
> >
> > John
> >
> > On Wed, Feb 22, 2017 at 5:18 PM John D. Ament <john.d.ament(a)gmail.com>
> > wrote:
> >
> >> Changing the subject to be a bit clearer about the problems.
> >>
> >> I think I'm understanding a bit further. when reading through
> >>
> https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/cl...
> >>
> >> - It seems like my application has to be SAML. I cannot do an OIDC
> based
> >> solution.
> >> - First thing I have to do is add IDP Initiated SSO URL Name to my
> >> application.
> >> - The confusing part is about if my application requires... this seems a
> >> bit odd, since I'm using the Keycloak adapter but sure.
> >> - The part that's missing is what gets setup in the actual broker. You
> >> mention IDP Initiated SSO URL Name but I don't see that field in IDPs.
> In
> >> general these look like Keycloak specific parameters.
> >>
> >> Any thoughts?
> >>
> >> John
> >>
> >> On Mon, Feb 20, 2017 at 7:18 AM John D. Ament <john.d.ament(a)gmail.com>
> >> wrote:
> >>
> >> Ok, so I was able to get SP initiated working fine. I had only tried
> IDP
> >> when I sent this mail out.
> >>
> >> I'm going through this doc, and its not clear to me on a few areas:
> >>
> https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/cl...
> >>
> >> - I have my application (the SP) and the SAML IDP (Okta in this case).
> I
> >> have a link on the okta portal to login automatically to my SP.
> >> - I think the webpage is saying that this only works if I'm using the
> SAML
> >> connector for keycloak, is that accurate?
> >> - All of my Okta settings are from getting SP initiated working. Do any
> >> of those need to change?
> >> - Do I in fact setup Okta as a SAML client in Keycloak?
> >>
> >> John
> >>
> >>
> >> On Sun, Feb 19, 2017 at 8:47 PM John D. Ament <john.d.ament(a)gmail.com>
> >> wrote:
> >>
> >> Hi
> >>
> >> Just wondering, has anyone setup Keycloak w/ Okta? Every time I try to
> >> authenticate (both SP initiated and IdP initiated) it fails with this
> error
> >>
> >> 01:40:54,626 WARN [org.keycloak.events] (default task-7)
> >> type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=tenant1, clientId=null,
> >> userId=null, ipAddress=172.17.0.1, error=staleCodeMessage
> >> 01:40:54,627 ERROR
> [org.keycloak.services.resources.IdentityBrokerService]
> >> (default task-7) staleCodeMessage
> >>
> >> I suspect its a setup issue on my side, so was hoping someone else has
> >> tried this and can give tips. I even tried the import feature, no luck.
> >>
> >> John
> >>
> >>
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
7 years, 9 months
Authenticate a rest api using keycloak access token
by Saransh Kumar
Hello,
How to get user information like username,name, email etc. from the
keycloak token in server side node js REST API (secured through bearer auth
only )?
--------------------------------------------------------------------------------------------------------------------------------------------
*Code:*
var express = require('express');
var router = express.Router();
var app = express();
var cors = require('cors');
var Keycloak = require('keycloak-connect');
var session = require('express-session');
var memoryStore = new session.MemoryStore();
app.use(session({
secret: 'c214ad7b-e4f9-4b11-9d79-d25084e7c721',
resave: false,
saveUninitialized: true,
store: memoryStore
}));
var keycloak =new Keycloak({store: memoryStore});
app.use( keycloak.middleware({logout: '/logout', admin: '/',}));
router.options('/', cors());
/* GET users listing. */
//router.get('/',keycloak.protect(),function(req, res, next) {
router.get('/', cors(),function(req, res, next) {
if (keycloak.protect())
{
// How to fetch userInfo here?
res.send('Reached here!');
}
else
{
res.send('Failed to authenticate');
}
});
module.exports = router;
------------------------------------------------------------------------------------------------------------------------------------------
Also, is there any method so that we can cache the user data from the token
assigned to a particular user, so that whenever request from the same user
comes again with the same token, we need not query keycloak about the user
information?
Thanks in advance
Saransh
7 years, 9 months
Restrict access to a client to a subset of Keycloak users
by Shane Boulden
Hi everyone,
I'm trying to figure out a fairly straight-forward problem set -
- I have a number of users in a Keycloak database, federated from an
LDAP provider with a READ_ONLY policy (ie; I can't "disable" the users)
- I want to limit access to a client to only certain Keycloak users
I thought this would be possible with a role that is shared by the client
and the user. However, it looks like Keycloak lets the application itself
determine access via a role: http://lists.jboss.org/
pipermail/keycloak-user/2014-November/001205.html
But what if I can't update the application's behaviour? Eg; if I want to
integrate Keycloak with OpenShift, and OpenShift doesn't consume any
information from the OIDC provider?
In this particular example, I don't want to limit the users in the Keycloak
database - I want to sync all users from LDAP, but limit application access
to only a subset.
Any assistance is greatly appreciated.
Shane
7 years, 9 months
Re: [keycloak-user] Quick help request
by Bill Burke
There is an add-user.sh script.
On 2/24/17 3:23 PM, Mark True wrote:
> Hi Team,
>
> I am doing the quick start for RH-SSO and I was trying to set up user federation with LDAP, in the process of doing so I accidentally deleted my only user with admin permissions.
>
> It doesn’t seem like there is a way to fix this, and there was no prohibition or warning about doing so given by the app! This seems like something that could be potentially bad in a live setup with thousands of users, but I do not feel like I know the system enough to call it a proper “bug”. Thoughts?
>
> For my purposes though, Is there a way I can add an admin user back manually or do I need to reinstall?
>
> —Mark True
7 years, 9 months
'Service Accounts Enabled' Client Setting Not Honored During Import
by Jeremy Majors
In order to have repeatable deployments of my companies keycloak instances I'm trying to use the import feature of keycloak to ensure that the clients are setup the same way in each environment. ? I have noticed that when I import a client, as opposed to the realm, the 'Authorization Enabled' flag is not set to true even if I have set it to true in the JSON that I'm importing. If I try to set it to true after importing I get an error unless I first turn off 'Service Accounts Enabled' and then attempt to enable 'Authorization Enabled'.
The JSON that I'm sending is provided below:
{
"clientId" : "hello-world-authz-service",
"secret" : "secret",
"authorizationServicesEnabled" : True,
"enabled" : True,
"redirectUris" : [ "http://localhost:8080/hello-world-authz-service/*" ],
"baseUrl": "http://localhost:8080/hello-world-authz-service",
"adminUrl": "http://localhost:8080/hello-world-authz-service",
"directAccessGrantsEnabled" : True
}
The JSON above is actually based upon one of the examples that was provided in the keycloak source code and it works when I import everything as a realm, but not when I use just the client portion.
Can anyone provide guidance in regards to how I can import JSON into Keycloak in order to setup a specific client?
This is the entire realm json file I refered to: https://github.com/keycloak/keycloak/blob/master/examples/authz/hello-wor...
I'm running keycloak version 2.5.0.Final Community.
Thank you in advance for your guidance,
Jeremy?
Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it.
7 years, 9 months
SAML2.0 Identity Provider modify authn context / extensions
by Martin Hardselius
Hi,
Is there an easy way to add stuff to the authn context or add extensions to
the AuthN request? Or even add query parameters to the destination url?
Context:
The SAML2.0 Provider I'm integrating with supports several auth methods.
Usually you would end up on a method select page, where the options are
presented to you, once you've been forwarded to the IDP. They do however
support selecting an option directly by modifying the authncontext. They
also support prefilling information by adding extensions to the authn
request or adding supplying it through query params. Kind of like "login
hint".
So. Easy way, or do I have to extend SAMLIdentityProvider?
Martin
7 years, 9 months
Best practices for multi-realm user management with Keycloak-Admin-Client
by Thomas Darimont
Hello Group,
What's the current best practice to manage users in multiple realms via
the keycloak-admin-client?
A simple variant is to create a dedicated confidential client
"internal-realm-admin" in
the master realm with only "direct access grants: on" and "service
accounts enabled: on"
and "standards flow enabled: off".
Given that the Keycloak contains two other realms "tenant1" and "tenant2"
besides master
we want to enable the service account for "internal-realm-admin" to manage
users (CRUD)
for those realms only.
Now this service client gets the following service-account client roles:
* "tenant1-realm": "manage-users" and "view-clients" (to list the
applications)
* "tenant2-realm": "manage-users" and "view-clients" (to list the
applications)
Now one can use this single client in a centralized service to manage both
realms
with a keycloak-admin-client constructed like this:
KeycloakBuilder.builder() //
.realm("master")
.serverUrl("http://192.168.99.1:8080/auth")
.clientId("internal-realm-manager")
.clientSecret("SECRET")
.grantType(OAuth2Constants.CLIENT_CREDENTIALS)
.build();
To manage users in tenant1 one can now do something like that:
keycloak.realm("tenant1").users().create(userRepresentation)
and for tenant2 ...
keycloak.realm("tenant2").users().create(userRepresentation)
Some Advantages:
+ one can globally manage users via a single centralized client
+ you can quickly generate a new secret for this single service
+ you don't need a dedicated user to manage other users
Some Disadvantages
- in certain environments this can be seen as a too privileged user / client
- user management operations are performed with the client service account
and not a "real" user
I think with this approach one is quite flexible and still has the
possibility to create
a dedicated (tenant) realm admin user / client and exclude it from the
"internal-realm-admin"
for tenants who needs explicity control over their user management.
Thoughts?
Cheers,
Thomas
7 years, 9 months
