OK, I finally understand exactly what you want to contribute, but afraid
we'll have to reject it. We can not accept and maintain a custom protocol
for many reasons, including:
* It's a lot of work to maintain
* It needs documenting and understanding by users
* It's just a slightly different way to doing things than OIDC. In fact for
Identity Brokering there's not that much you need to implement the OIDC
part in the IdP
* It could contain security vulnerabilities
On 17 August 2017 at 08:47, 乗松隆志 / NORIMATSU,TAKASHI <
takashi.norimatsu.ws(a)hitachi.com> wrote:
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-with-external-login-server?et=notification.send
https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.
0/com.ibm.apic.toolkit.doc/tapim_sec_api_config_scheme_oauth_endpoint.html
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/master/src/keycloak/examples/providers/delegate-authn-consent
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/src/main/java/org/keycloak/broker/
provider/IdentityProvider.java
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-broker.html
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