Ok to have no direct links to...
by Bill Burke
I need some input.
It is ok for, registration page and social link buttons to only be
linkable from within a Keycloak login page?
The idea is that there would be a OAUTH specific and SAML specific login
page entry point where client ids are verified and a ClientSessionModel
is created. Registration page, social login links, required user
actions would all be driven by a ClientSession code and would not be
linkable to from the outside world. This allows those pages to be
completely separate from the login protocol being used.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
Re: [keycloak-dev] Keycloak Intergration
by Bill Burke
Sagar, I'm moving this to keycloak-dev list. See comments inline
On 9/25/2014 6:53 AM, Sagar Zond wrote:
> Hi,
>
> We are planning to use KeyClock for OAuth authorization server for our
> API platform. Our understanding to KeyClock and OAuth is not very clear
> so need your help to properly utilize KeyClock features.
>
> Just to introduce our self, we are a start-up firm and creating products
> for Health care domain. In our architecture we will have multiple Rest
> API servers and multiple types of client like mobile, web and publicly
> expose API. KeyCloak can be used as authentication and authorization
> server. We have already gone through most of KeyCloak tutorials.
>
> Here are few points of which we need answer -
>
> 1. API platform will be registered as application server on KeyClock and
> clients (mobile app, web app or other app) will be authorized by
> keyclock as per defined role. Is this a proper use case of KeyClock ?
>
You'll have to elaborate. I don't know exactly what you are saying.
Your REST API server would be registered as a Keycloak "Application".
You can define roles per "Application" or at the Realm level (global roles).
> 2. How do we integrate OAuth into mobile app ? Where can we write token
> refresh logic?
>
You can start off by defining an public "OAuth Client" per mobile app.
You can use the direct grant REST API to obtain a token, or, use mobile
redirects to login through the mobile's browser. I believe the Aerogear
project is doing some work around Keycloak IOS and Android clients, but
you'd have to ping them.
> 3. How we can add more fields in session? e.g. if we want to add more
> token in header which may contain some extra application specific
> encrypted data.
>
Not sure what you mean. We don't have a nice way of adding claims to
the token at the moment.
> 4. We are currently using OpenDS Ldap for authentication and we already
> have number of registered users which currently using API. So we need
> Keyclock to be configured for OpenDS, so please suggested how to
> integrate OpenDS with KeyClock.
>
We have LDAP integration:
http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/user_feder...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
need more time
by Bill Burke
I need more time on the refactoring of login actions. So far I've
refactored all the code to
* create a ClientSession when login page is visited
* Pass around a "client session code" as a query parameter that
references the client session
* Store state within the client session instead of in query and form
parameters
* Refactor Social login to use a client session. This allowed me to
remove the "KEYCLOAK_SOCIAL" cookie.
I have all this building correctly.
Next steps are to create a "protocol adapter" interface and have all
login actions use this adapter instead of being hardcoded to oauth. I
probably won't get this done until late next week. After that I'll
start on SAML and the "protocol adapter" interface will probably go
through another iteration.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
Update on clustering support
by Stian Thorgersen
A quick update on clustering work. The plan is:
* Infinispan User Session Provider - supports local, distributed and replicated modes / almost completed
* Infinispan Realm Cache - supports local and invalidation modes (should not be used in distributed/replicated modes) / almost completed
* Infinispan User Cache - supports local and invalidation modes (should not be used in distributed/replicated modes) / almost completed
* Clustering support for adapters
- Support stateless (no http session) and distributed http session / not started
- Support direct communication with Keycloak (avoid proxy when auth-server url is relative) / not started
* Security for clustering - use an interceptor to sign/verify messages with realm keys - question is, do we really need this? Nodes need to be on the same subnet, realm/users are invalidation only and the only thing a malicious node could do with user sessions is to prevent them from expiring.
* Docker config for setting up test environment / almost completed
* Cluster testsuite / not started
* Jenkins clustering tests / not sure we'll get around to this
We're aiming to complete the above work by the end of the week, and release 1.1.0.Final with clustering support next week (or should we wait for SAML?).
With regards to using Infinispan for realm and user cache invalidation. Reasoning for using this instead of a custom solution include:
* Significantly less time to impl (took only ~2h to impl!)
* Multicast/jgroups is much more efficient compared to http messages
* No need to deal with cluster memberships, disconnect/partitions, etc ourselves
* Infinispan provides loads of configuration options (evictions, transports, cache-modes, etc.)
* Sensitive data never transferred between nodes (only invalidation messages)
* We can still sign messages with realm keys for security
* In theory we could also support distributed and replicated cache-modes in the future - not sure this makes sense (maybe for users only?), also we're certainly not doing it for this round
12 years
Resolving of relative redirectUri in cluster
by Marek Posolda
I wonder if it's ok to add possibility to WildFly/AS7 adapter for
alternative resolving of relative redirectUris. Currently it's always
retrieved from HTTP request sent by browser (ie. with relative uri
"/auth" and HTTP request is "http://localhost:8080/customer-portal" then
adapter is able to resolve the URI to "http://localhost:8080/auth"). Is
it ok to have possibility (perhaps boolean config option on adapter like
"preserve-hostname") to resolve them from the actual hostname instead of
browser request? Usually it's not much difference, but in cluster there
might be scenario like:
- Setup with loadbalancer on "http://frontend:8080" and 2 backend
cluster nodes "http://backend-node1:8080" and "http://backend-node2:8080"
- Then user filled login form. Now assume that request request with
code+state is processed on
"http://backend-node1:8080/customer-portal?code=...&state=..." . Now
adapter sends codeToToken exchanging request to relative URI, which is
resolved from browser to "http://frontend:8080". So adapter sends
request to loadbalancer, which is then resended back to one of backend
nodes. So 2 additional network hops needed.
So when there is possibility to resolve relative URI from hostname, then
backend-node1 will send exchanging request to itself instead of going
through loadbalancer. In cluster it should help to save performance and
reduce network communication.
Note that this will be configurable and will be used by adapters just
for backend requests (codeToToken, refresh token etc). All browser
redirects will still need to go through loadbalancer IMO, in usual
cluster environments are cluster nodes hidden in private network and URI
like "http://backend-node1:8080/auth" may not be available for users.
wdyt?
Marek
12 years
merge master to Branch_1_0
by Bill Burke
When I finish my initial refactoring to allow multi-protocol login, I'm
going to merge master to Branch_1_0 first. After the security audit
team is done with Keycloak, I'll do a 1.0.2 release from this branch.
Is there anything currently in master that shouldn't be in 1.0.2?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
UserSession changes required for SAML
by Bill Burke
There's a few problems with UserSession and AccessCode and screen flows
* UserSession and AccessCode is hard wired to oauth protocol
* userSession is not created until credentials have been entered
* SAML has state that needs to hang around until final redirect back to
client
* Final redirect needs to know the protocol that started the login.
* Screen flows assume various query parameters are set (client_id, etc.)
So here's the changes:
* UserSessions will be created when the login page is first visited if
the user hasn't already logged in.
* ClientSession will also be created when login page is visited.
setAuthMethod for the ClientSession will be set so that later on, when
the final redirect happens, the auth server will know which protocol to use
* ClientSession will have a generic string hashmap
(ClientSession.getNotes()) where you can store arbitrary state. (i.e.
like HttpSession, but specific to the client).
* ClientSession.getState() will be removed and put in
ClientSession.getNotes()
* AccessCode needs to expose the ClientSession instead of hiding and
delegating to it.
* Screen flows will access the ClientSession for all information required.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
