[keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication

Thu Aug 17 02:53:53 EDT 2017

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 at 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 at redhat.com'
> Cc: 'keycloak-dev at 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 at redhat.com]
> Sent: Tuesday, August 15, 2017 4:49 PM
> To: 乗松隆志 / NORIMATSU，TAKASHI
> Cc: keycloak-dev at 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 at 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 at redhat.com]
> Sent: Monday, August 14, 2017 7:57 PM
> To: 乗松隆志 / NORIMATSU，TAKASHI
> Cc: keycloak-dev at 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 at 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 at redhat.com]
> Sent: Thursday, June 29, 2017 6:23 PM
> To: 乗松隆志 / NORIMATSU，TAKASHI
> Cc: keycloak-dev at 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 at 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 at redhat.com]
> Sent: Tuesday, June 27, 2017 5:52 PM
> To: 乗松隆志 / NORIMATSU，TAKASHI
> Cc: keycloak-dev at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>