Scope Param with Keycloak
by Tomas Cerny
Hi all,
I am trying to use the scope param with keycloak, which is part of the open
id
http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Here is an sample URL (from
https://openid.net/specs/openid-connect-basic-1_0.html#AuthenticationRequest
)
Which is
https://server.example.com/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
note the state param there
with keycloak this is my auth URL:
http://127.0.0.1:8080/auth/realms/example/protocol/openid-connect/auth?cl...
When I pass scope param, then it is ignored.
Does keycloak support scope param? Can I intercept it to make a custom
handler? (e.g. lookup DB data)
Sample Use Case: Keycloak has my custom UserFederation provides where I
issue user lookup to my SQL DB, and determine access, next basing on the
scope I like to post back to the app roles relevant to the scope param.
I know keycloak has static roles, but I need it contextual, such as - user
is master in scope = A, but reader in scope = B. Since the range of scopes
is dynamic and large, the use of client-ids is not sufficient.
I assume the scope can help me solving situation such as am I owned of an
object?
I did days of debugging keycloak code and cannot find much even thought
there is OAuth2Constants.Scope but may be that is something different?
and I seem some dead sample here: FishEye: changeset
d309fab8251d95f50f94c77e4d08e6e8c2977994
<https://source.jboss.org/changelog/Keycloak?cs=d309fab8251d95f50f94c77e4d...>
The alternative OpenAM supports scope param it - OpenAM Project - About
OpenAM <http://openam.forgerock.org/>
Thanks, Tom
Here a forum public users.
https://developer.jboss.org/message/934762#934762
8 years, 2 months
Thinking about step-up authentication and token timeouts
by Stian Thorgersen
Clients should be able to obtain tokens with reduced scope and longer or
shorter expiration, then later request new tokens with increased scope and
different expiration. They should also be able to require different levels
of authentication and also require re-authentication.
An application may for example:
* At first only need users email - this would allow showing the name +
email. In this situation a long expiration access token in combination with
implicit flow would do. It's also not necessary to re-authenticate the user
and a user that has been logged-in for months or even a year is fine.
* When a user clicks on orders it would require the password and extend
scope to be able to view orders. Now you'll want to switch to short
expiration access tokens and authorization code grant. You'll also want to
make sure the user logged-in fairly recently, max 30 days could be sensible.
* When a user tries to purchase something the user now has to provide the
OTP to be able to purchase with saved credit card details. You'll also want
to make sure the user logged-in very recently, max a day could be required.
There may also be cases where you always want the user to re-authenticate,
for example when trying to purchase something over a certain price level.
8 years, 8 months
(no subject)
by Luke Holmquist
I have a use case, that i think could be pretty common, but i'm not
entirely sure how to setup it up.
The following is a little bit of a thought dump, so pardon me if i ramble a
little bit.
There are i think 3 components involved here:
1. a pure HTML/JS web app
2. A node.js REST API server
3. Keycloak server
The app in this case, would not be served by the node server or the KC
server(wildfly), but with something like nginx(or even something like
'python simpleHTTPServer')
Basically the flow would be something like this[1]:
The web app, using the js adapter, authenticates against the KC server.
Now the web app would like to call the node API server(a restricted
endpoint) to get some data
The web app probably adds the token stuff that it got from KC during it;s
login to the request to the node server
***This next part is where i'm getting a little confused, i'm aware that
code to do this might not be written yet****
I'm thinking the node server takes the token from the web app request, and
would hit an endpoint on the KC server to make sure that token is valid.
If things go ok, then node server returns the data.
I've seen the recent post on doing token introspection and abstracj was
nice enough to make that into a gist,
https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
but this would also mean the web client access_type would need to be
confidential(which i don't think is secure for a web app) to make a service
account that the node server could use to do the token introspection.
I was thinking of maybe creating a client also for the node server, but is
it possible for 1 client to lookup/validate tokens from another client.
Perhaps i'm thinking about this all wrong too, which is very possible.
In this example there is only 1 node api server, but there could be
multiple node/go/rust/<insert cool kid tech here> servers too
Any guidance would be appreciated and sorry for the ramble
-Luke
[1]
https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROY...
8 years, 8 months
Re: [keycloak-dev] html app, node api server and keycloak
by Luke Holmquist
crap, forget the subject line
On Fri, Apr 29, 2016 at 1:09 PM, Luke Holmquist <lholmqui(a)redhat.com> wrote:
> I have a use case, that i think could be pretty common, but i'm not
> entirely sure how to setup it up.
>
> The following is a little bit of a thought dump, so pardon me if i ramble
> a little bit.
>
>
> There are i think 3 components involved here:
>
> 1. a pure HTML/JS web app
>
> 2. A node.js REST API server
>
> 3. Keycloak server
>
>
> The app in this case, would not be served by the node server or the KC
> server(wildfly), but with something like nginx(or even something like
> 'python simpleHTTPServer')
>
> Basically the flow would be something like this[1]:
>
> The web app, using the js adapter, authenticates against the KC server.
>
> Now the web app would like to call the node API server(a restricted
> endpoint) to get some data
>
> The web app probably adds the token stuff that it got from KC during it;s
> login to the request to the node server
>
> ***This next part is where i'm getting a little confused, i'm aware that
> code to do this might not be written yet****
>
> I'm thinking the node server takes the token from the web app request, and
> would hit an endpoint on the KC server to make sure that token is valid.
>
> If things go ok, then node server returns the data.
>
> I've seen the recent post on doing token introspection and abstracj was
> nice enough to make that into a gist,
> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
>
> but this would also mean the web client access_type would need to be
> confidential(which i don't think is secure for a web app) to make a service
> account that the node server could use to do the token introspection.
>
> I was thinking of maybe creating a client also for the node server, but is
> it possible for 1 client to lookup/validate tokens from another client.
>
>
> Perhaps i'm thinking about this all wrong too, which is very possible.
>
> In this example there is only 1 node api server, but there could be
> multiple node/go/rust/<insert cool kid tech here> servers too
>
>
>
> Any guidance would be appreciated and sorry for the ramble
>
> -Luke
>
>
>
>
>
>
> [1]
> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROY...
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
8 years, 8 months
Re: [keycloak-dev] User Federation provider instances
by Stian Thorgersen
We have 3 types of providers:
* Server configured - no config or config from keycloak-server
* Realm configured - config from realm model
* Instance configured - multiple instances per realm
Removing master realm as we plan to do means that realm configured provider
factories can get realm from KeycloakContext as there's only one realm
per-session.
For instance configured I propose we add getProvider(Class c, String id,
String instanceId) to provider factory. The it's up to the provider factory
itself to extract the config from the realm model or another source. It
also means that the session can easily keep track of these and only create
one id+instanceId per session.
On 29 Apr 2016 09:43, "Marek Posolda" <mposolda(a)redhat.com> wrote:
Yes, AFAIK we have open JIRA for this for a long time ago.
It's the same issue for IdentityProvider (and maybe some others SPI too)
that they bypass "official" way for create provider via
session.getProvider(providerClazz) and hence they are not registered in
KeycloakSession and "close" method is not called for them.
The issue is that our SPI is a bit limited IMO and doesn't support
"stateful" providers. The providers are created through
"ProviderFactory.create(KeycloakSession)". So the only available state of
provider ATM is just ProviderFactory + KeycloakSession, which is sometimes
not sufficient.
I can see 2 possibilities to address:
1) Always make the provider implementation "stateless" and ensure all the
state is passed as argument to provider methods. This is what we already do
for some providers (for example all methods of UserProvider has RealmModel
as parameter). So if we rewrite UserFederation SPI that
UserFederationProviderModel will be passed as argument to all methods of
UserFederationProvider, then it can use "official" way too.
2) Improve the SPI, so it can properly support "stateful" providers. This
is more flexible then (1) and I would go this way long term.
I am thinking about something like this:
public interface StatefulProvider<S> extends Provider {
}
public class StatefulProviderFactory<T extends StatefulProvider, S> {
T create(KeycloakSession session, S state);
.......
}
and on KEycloakSession new method like this:
<S, T extends StatefulProvider<S>> T getProvider(Class<T>
providerClazz, String id, S state);
The "state" will need to properly implement equals and hashCode, so the SPI
can deal with it and not create another instance of StatefulProvider if it
was called for this KeycloakSession with same state before.
Marek
On 29/04/16 08:00, Stian Thorgersen wrote:
Looking at the code for user federation it looks like user federation
provider instances with the same configuration can be created multiple
times for a single session. Also they are never closed to resources aren't
released.
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
8 years, 8 months
SSO does not work if more than one federation provider (ldap with kerberos) is registered
by May Marcus, Bedag
Hi, I would like to propose an enhancement to the selection of an federation provider (ldap with kerberos).
I tried to register two federation providers (ldap with kerberos) to support SSO for users in two different kerberos realms. The problem is that only the first (according to attribute priority) will be used to authenticate the user. Authentication of users from the other federation provider with kerberos does not work.
I think the selection of the federation provider to use could be improved in the code to solve this issue. I found the following code fragment in "org.keycloak.models.UserFederationManager.validCredentials(KeycloakSession, RealmModel, UserCredentialModel...)":
// Find first provider, which supports required credential type
for (UserFederationProvider fedProvider : fedProviders) {
if (fedProvider.getSupportedCredentialTypes().contains(cred.getType())) {
providerSupportingCreds = fedProvider;
break;
}
}
In case of kerberos the federation provider could be chosen based on the kerberos realm in the ticket and the configured kerberos realm.
Can I just create an issue of type enhancement in jira?
Marcus
8 years, 8 months
User Federation provider instances
by Stian Thorgersen
Looking at the code for user federation it looks like user federation
provider instances with the same configuration can be created multiple
times for a single session. Also they are never closed to resources aren't
released.
8 years, 8 months
