Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication
by 乗松隆志 / NORIMATSU，TAKASHI
Hello.
>So rather than using standard protocols (OIDC or SAML) you've come up with your own custom protocol that folks would have to implement instead?
Yes, but much easier for people than using OIDC/SAML.
If OIDC is used for the existing authentication server, following OIDC OP functions would have to be implemented.
- Authz Code Flow (at least)
- Authz Code management
- ID Token/Access Token management
- JWT
- JWS
- key management for JWT
Instead, if supporting the simplified protocol such the one I have proposed, only following would have to be implemented
- Issue temporal opaque ticket
- Send authenticated user info in return to this ticket
Regards
Takashi Norimatsu
-----Original Message-----
From: 乗松隆志 / NORIMATSU，TAKASHI
Sent: Thursday, August 17, 2017 11:24 AM
To: 'stian(a)redhat.com'
Cc: 'keycloak-dev(a)lists.jboss.org'
Subject: RE: [!]Re: Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication
We do NOT intend to propose a "custom"(customer specific) brokering protocol, are proposing a simplified brokering procedure for an external authentication server without implementing OIDC/SAML.
This is useful for users who have their existing authentication server. They had to implement OIDC/SAML(very hard) or had to design and implement another procedure(is also not easy). By the proposal, they can integrate their authentication server easily.
For example, UMA standard for authorization service is proposed, but seems to be complicated, so keycloak has simplified procedure(entitlement API). Feature is different but situation is the same (simplified OIDC/SAML).
----------
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Tuesday, August 15, 2017 4:49 PM
To: 乗松隆志 / NORIMATSU，TAKASHI
Cc: keycloak-dev(a)lists.jboss.org
Subject: [!]Re: Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication
Afraid I still don't understand what you are trying to contribute to Keycloak. As I said we already allow creating custom identity providers using whatever protocol you want. We can't accept contribution of a custom identity provider which is seems is what you are trying to contribute.
On 15 August 2017 at 08:58, 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com> wrote:
> I'm not really following what you are proposing to contribute to Keycloak.
Thank you for comment.
This contribution to keycloak is that to enhance competitiveness with proprietary products.
In some market, customers have highly customized Web UI for authentication.
(e.g. soft keyboard, responsive web design, very sophisticated look and feel).
They want to use Authorization server product (such as keycloak) implementing OpenID Connect for securing the customer's API.
They want to use existing highly customized authentication server, but do not want to implement OpenID Connect on this authentication server (too much complex and difficult to implement).
To meet such needs, proprietary products have the following solution.
Proprietary authorization server products have their own procedure (much simpler than OpenID Connect and SAMLv2) to communicate with existing authentication server as below:
https://communities.ca.com/blogs/oauth/2016/10/04/howto-integrating-otk-w...
https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic....
In customer's existing authentication server, customers only have to implement communication with the authorization server according to the procedure prepared by the authorization server product (It is much easier than implementing OpenID Connect or SAMLv2). Customers do not have to implement anything in authorization server side.
On the other hand, if keycloak is used, customers have to do following:
a) In authorization server (RH SSO), simple procedure to communicate with external authentication server have to be designed and implemented using SPI.
b) In customer's existing authentication server, implement procedure prepared by a).
-> In proprietary products, a) is prepared, but keycloak is not.
Our proposed patch is intended to complement a).
---
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Monday, August 14, 2017 7:57 PM
To: 乗松隆志 / NORIMATSU，TAKASHI
Cc: keycloak-dev(a)lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication
I'm not really following what you are proposing to contribute to Keycloak. We already have the SPI that allows adding a custom provider if your IdP doesn't support SAML or OpenID Connect.
On 31 July 2017 at 06:09, 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com> wrote:
Hello.
Previously, I had proposed the feature and its implementation of delegating authentication and authorization to an external existing server on behalf of keycloak's browser-based authentication mechanism, and had gotten advices that it is appropriate to use Identity Brokering for such the feature.
I've re-implemented this feature again by Identity Brokering. The description and implementation of this feature is mentioned below.
https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent
https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent/tree/maste...
It can delegate not only authentication but authorization(consent).
Kindly review it and provide us some comment and advices.
We would like to contribute this feature onto keycloak.
Best Regards
Takashi Norimatsu
Hitachi, Ltd.
---
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Thursday, June 29, 2017 6:23 PM
To: 乗松隆志 / NORIMATSU，TAKASHI
Cc: keycloak-dev(a)lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication
There's an SPI to implement your own custom identity brokering provider [1].
[1] https://github.com/keycloak/keycloak/blob/master/server-spi-private/sr...
On 29 June 2017 at 10:51, 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com> wrote:
I need to use the authentication server without OIDC/OAuth2/SAMLv2 implementation as an external IdP, in order to integrate existing authentication system.
(some commercial products supports such the case)
I consulted identity broker's section in keycloak's manual below and found that if I use this feature the external IdP must support OIDC or SAMLv2.
https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-b...
Therefore, I realized it by using redirect based authentication flows.
Can identity Brokering can support such the case?
Aside from this, I'd like to contribute it to Community extensions and examples.
Best Regards
Takashi Norimatsu
Hitachi, Ltd.
---
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Tuesday, June 27, 2017 5:52 PM
To: 乗松隆志 / NORIMATSU，TAKASHI
Cc: keycloak-dev(a)lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication
I'm not in favour of adding this. If it's using redirect based authentication flows it should be done through identity brokering, not authentication flows. It's also a very complex example that we don't want to maintain. We've also in the process of moving all examples away from the main Keycloak repository into a separate quickstart repository.
On 27 June 2017 at 08:54, 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com> wrote:
Hello.
Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism.
I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260).
Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak.
Detailed description of this feature is mentioned below.
https://github.com/Hitachi/PoV-keycloak-authentication-delegation
I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem?
[Problem]
- I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases.
After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers.
Best Regards
Takashi Norimatsu
Hitachi, Ltd.
_______________________________________________
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9 years
Adding notBefore to user?
by Marek Posolda
I am thinking about adding notBefore to user. It will be updated when
user logouts in Account management or when admin logouts user in admin
console.
I am thinking about this because in cross-dc environment, it can happen
under some circumstances that particular userSession "123" is not
available in infinispan cache on any Keycloak server, however it's
available on the remoteCache on JDG server. So it can happen that:
- Admin press "Logout all sessions", but session 123 won't be affected
as it's available just on remoteCache
- Someone (attacker) sends refresh token for session 123. It will be
loaded from remoteCache store to Keycloak cache and will be treated as
valid session.
Do you think it's bad idea to add notBefore to user? There may be some
other ways to mitigate the issue if you think it's bad.
I am thinking about adding it to separate table, so it's persistent
among server restarts even for users from federated user storages.
Something similar to like consents are saved. WDYT?
Marek
9 years, 1 month
Big changes coming to docs
by Stian Thorgersen
As part of unifying Keycloak and RH-SSO documentation we are moving away
from Gitbook soon and will use pure AsciiDoctor to build the Keycloak
documentation.
This will be done after Keycloak 3.3 is released and there will be a period
of 1-2 weeks where I don't want anyone to make any changes to the
documentation while this work is in progress.
So get your docs changes in before 3.3. If they're not there in time hold
off until I give the OK.
If you make edits to the docs in your own fork you will not easily be able
to merge it to the repository after these changes and you will most likely
have to re-edit the docs.
9 years, 1 month
remove jboss-client.jar?
by Bill Burke
FYI,
Our distro is 17M bigger because we include jboss.client.jar. This jar
is uber jar by Java clients that want to talk to server (stubs, jndi,
etc.), but its 17M.
Bill
9 years, 1 month
jarless Keycloak distro
by Bill Burke
Did you know with a flip of a switch that a jarless Keycloak distro can
be created? Just edit <root>/distribution/server-provisioning.xml and
remove extraction params:
<server-provisioning xmlns="urn:wildfly:server-provisioning:1.2"
extract-schemas="true">
<feature-packs>
<feature-pack groupId="org.keycloak"
artifactId="keycloak-server-feature-pack" version="${project.version}"/>
</feature-packs>
</server-provisioning>
All the module.xml reference maven artifacts and when you boot the
distro it tries by default to resolve them in ~/.m2, you can even point
it to a remote distro and it will download the jars.
9 years, 1 month
token exchange permission model
by Bill Burke
Right now I have a "exchange-from" and "exchange-to" permission when
exchanging client->client tokens. I'm wondering if an "exchange-from"
permission needs to exist? Would we ever have the case where a client
is allowed to "exchange-to", but not "exchange-from"? I'm thinking this
is just overboard and would rarely be used.
Bill
9 years, 1 month
Setup 'keycloak-security' mailing list
by Stian Thorgersen
We need to have a dedicated place to report and discuss security
vulnerabilities. This should be a list anyone can send to, but only
specific people can subscribe to.
I'd like to create a new mailing list 'keycloak-security' for this purpose
and have everyone on the team subscribed.
Thoughts? Suggestions to alternative approaches?
9 years, 1 month
