[Apiman-user] Replacing Keycloak

Eric Wittmann eric.wittmann at redhat.com
Wed Jan 27 12:11:57 EST 2016 

I hadn't seen pac4j before (not sure how I've missed it) but it looks 
like an interesting approach.

Definitely the first step is using it to secure the apiman web 
application(s).  As you say - that means replacing the Keycloak adapter 
layer.

The hardest part (I'm guessing) will be getting access to the bearer 
token so that the UI can make direct, authenticated calls to /apiman 
using it.

We can get this done iteratively I think - with step #1 definitely being 
to secure /apimanui (replacing the keycloak adapter authentication we 
currently use).

-Eric

On 1/26/2016 8:08 AM, Amit Joshi wrote:
> Hello,
>
> Thanks for the help. I am checking with the internal folks to check that
> I can share out the PF code (I don’t anticipate any issues but need to
> make sure).
>
> I read through the code a little bit and it appears that the best
> approach would be to have a Openidc adapter (since Ping Federate
> supports that directly). I am looking at the Keycloak adapter to see if
> I can use that code or whether there is some other library that will
> provide Openidc support directly into JEE - I am more familiar with
> Spring where Oauth2 support for external Oauth2 servers is part of
> Spring Security. I was thinking of looking at pac4j
> (http://www.pac4j.org/) that is Apache 2 licensed and claims to have
> full security token support (Oauth, Openid Connect, ...) for JEE. The
> approach I was thinking of:
>
> 1.Use the library to get a  login security filter, replacing the
> KeyCloakLoginModule.
>
> 2.Save the token similar to Keycloak
>
> 3.Reuse the token for the API authentication.
>
> 4.If that works then it should be able to authenticate against pretty
> much any other implementation (I would suspect even against Keycloak)
> directly.
>
> Let me know what you think of the approach.
>
> Regards,
>
> Amit Joshi
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Monday, January 25, 2016 4:08 PM
> To: Amit Joshi; apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Replacing Keycloak
>
> OK great - we're on the same page then.  Happy to help (and then reap
> the benefits of your work in apiman!).  :)
>
> We need to split the problem up into two.  The first (and probably
>
> harder) problem is supporting PF as an authentication mechanism for
> apiman.  The second problem is protecting managed APIs with PF.
>
> #1 Apiman Auth via PF
>
> ---------------------
>
> * Can you share your PF sample java app?
>
> * There are three WARs that will need to be protected:
>
>      - apiman.war
>
>      - apiman-gateway-api.war
>
>      - apimanui.war
>
> * !!!!!!  Let's focus first on "apimanui.war", which is a standard java
> web application.  !!!!!!!!
>
> * We will need to secure the WAR with PF *and* provide a PF-specific
> impl of ISecurityContext.  There are two impls thus far,
> DefaultSecurityContext and KeycloakSecurityContext.  If the PF
> authentication code puts the auth principal and roles into the servlet
> request, then you can use DefaultSecurityContext.  If not, a custom impl
> may be required (see the KC impl for more info).
>
> http://bit.ly/1ZZAmwW
>
> * The security context is configured here:
>
> http://bit.ly/1KAvu51
>
> * After the user logs into the UI, the UI will then use the oauth bearer
> token to make authenticated calls directly from the UI to the API
> Manager REST layer.  This bearer token is periodically refreshed by
> making a call to the /apimanui/ context to get a new token.  This is
> what is called:  ITokenGenerator
>
> * Assuming PF uses bearer tokens, we'll need a PF implementation of the
> above interface.  See KeyCloakBearerTokenGenerator for more information.
>
> * Note: the keycloak plugin you are looking at is *not* the code that is
> called when logging into apiman.  For that, you'd have to look at the
> keycloak adapter code:
>
> https://github.com/keycloak/keycloak/tree/master/adapters
>
> #2 Protected Managed APIs with PF
>
> ---------------------------------
>
> * Our OAuth support is a keycloak-specific apiman policy that I think
> you've already discovered:
>
> https://github.com/apiman/apiman-plugins/tree/master/keycloak-oauth-policy
>
> * Adding PF authentication support will require a *new* plugin specific
> to PF.
>
> -------------------
>
> OK that's a lot, I know.  Let's start with your PF enabled java app and
> try to apply those principals to the API Manager UI.
>
> -Eric
>
> On 1/25/2016 3:47 PM, Amit Joshi wrote:
>
>  > Hello,
>
>  >
>
>  > I am trying to use Ping Federate for both login and for the API
> restrictions.
>
>  >
>
>  > I understand that integrating into Ping Federate might not be trivial
> and might require some hacking into the APIMan code. I have created a
> sample java app that does the SP initiated login for ping federate that
> works. However with APIMan I am lost as to where to start ... I tried to
> look at the apiman-plugin-keycloak-oauth-policy to see but I suspect
> that it will take me some time to trace through it and figured that
> people working on the product might be able to get me started quicker.
>
>  >
>
>  > In short, happy to help hack on the code but will need the touch
> points.  I assume there is some code somewhere that checks if the token
> already exists and if not then generates the auth request, gets the
> access code, validates the code and generates the token?
>
>  >
>
>  > Regards,
>
>  >
>
>  > Amit Joshi
>
>  >
>
>  > -----Original Message-----
>
>  > From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
>
>  > Sent: Monday, January 25, 2016 3:37 PM
>
>  > To: Amit Joshi; apiman-user at lists.jboss.org
> <mailto:apiman-user at lists.jboss.org>
>
>  > Subject: Re: [Apiman-user] Replacing Keycloak
>
>  >
>
>  > Hi Amit.
>
>  >
>
>  > To be clear, you are trying to replace Keycloak as the authentication
> mechanism for logging into the apiman UI, correct?
>
>  >
>
>  > I can't say I know how to configure a web application to use
> pingfederate for authenticaiton (never done that before).  But I can
> tell you that it's likely that you will not be able to use the settings
> in standalone-apiman.xml because those are configuration settings for
> the keycloak auth client adapter.  The client adapter is the keycloak
> specific client that handles authentication redirects to the auth
> server.  I *assume* this adapter is keycloak-specific.
>
>  >
>
>  > In order to get pingfederate working I must assume that they
>
>  > (pingfederate) have some documentation for how to configure a java
> web application for authentication.  Sadly their documentation server
> seems to be broken at the moment.
>
>  >
>
>  > I'll warn you that, while I'm sure using pingfederate is *possible*,
> it is probably not trivial.  You may need to contribute some code to
> apiman in order to enable support in the UI, for example.  If hacking
> some code is not a daunting prospect then I'd be happy to help point you
> in the direction of all the authentication touch points...
>
>  >
>
>  > -Eric
>
>  >
>
>  >
>
>  > On 1/25/2016 3:18 PM, Amit Joshi wrote:
>
>  >> Hello,
>
>  >>
>
>  >> I have the following setup:
>
>  >>
>
>  >> Ping server -> external https url  (something like
>
>  >> https://pingfederate.mydomain.com) - through an apache reverse proxy.
>
>  >> Real server is pingfederate001.internal.com.
>
>  >>
>
>  >> APIman  -> external https url (something like
>
>  >> https://apiman.mydomain.com) through ab apache reverse proxy. Real
>
>  >> server is apiman001.internal.com.
>
>  >>
>
>  >> I am trying to replace keycloak with ping federate in APIMan.  I have
>
>  >>
>
>  >> -Disabled the integrated Keycloak.
>
>  >>
>
>  >> -Changed the
>
>  >> <kc:auth-server-url>https://pingfederate.mydomain.com/as/token.oauth2
>
>  >> <
>
>  >> /kc:auth-server-url
>
>  >> <https://pingfederate.mydomain.com/as/token.oauth2%3c/kc:auth-server-
>
>  >> u
>
>  >> rl>>
>
>  >>
>
>  >> However, when I access I see the following as the redirect - which is
>
>  >> clearly wrong:
>
>  >>
>
>  >>
> https://pingfederate.mydomain.com/as/token.oauth2/relams/apiman/protocol/openid_connect/auth?
>
>  >>
>
>  >> with the following parameters:
>
>  >>
>
>  >> response_type=code
>
>  >>
>
>  >> client_id=apimanui
>
>  >>
>
>  >> redirect_uri=http://apiman001.internal.com
>
>  >>
>
>  >> I looked the code for the keycloak plugin but can't seem to see where
>
>  >> the redirect is generated or set. I assume it is some additional
>
>  >> properties or settings that I have to do or change code for so I can
>
>  >> generate a Ping friendly redirect url etc.
>
>  >>
>
>  >> Appreciate any help or any pointers.
>
>  >>
>
>  >> Regards,
>
>  >>
>
>  >> Amit Joshi
>
>  >>
>
>  >>
>
>  >> ---------------------------------------------------------------------
>
>  >> -
>
>  >> --
>
>  >>
>
>  >> This e-mail, including accompanying communications and attachments,
>
>  >> is strictly confidential and only for the intended recipient. Any
>
>  >> retention, use or disclosure not expressly authorised by Markit is
>
>  >> prohibited. This email is subject to all waivers and other terms at
>
>  >> the following link:
>
>  >> http://www.markit.com/en/about/legal/email-disclaimer.page
>
>  >>
>
>  >> Please visit http://www.markit.com/en/about/contact/contact-us.page
>
>  >> for contact information on our offices worldwide.
>
>  >>
>
>  >>
>
>  >> _______________________________________________
>
>  >> Apiman-user mailing list
>
>  >> Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>
>  >> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>  >>
>
>  >
>
>  > ________________________________
>
>  >
>
>  > This e-mail, including accompanying communications and attachments, is
>
>  > strictly confidential and only for the intended recipient. Any
>
>  > retention, use or disclosure not expressly authorised by Markit is
>
>  > prohibited. This email is subject to all waivers and other terms at
>
>  > the following link:
>
>  > http://www.markit.com/en/about/legal/email-disclaimer.page
>
>  >
>
>  > Please visit http://www.markit.com/en/about/contact/contact-us.page
> for contact information on our offices worldwide.
>
>  >
>
>
> ------------------------------------------------------------------------
>
> This e-mail, including accompanying communications and attachments, is
> strictly confidential and only for the intended recipient. Any
> retention, use or disclosure not expressly authorised by Markit is
> prohibited. This email is subject to all waivers and other terms at the
> following link: http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page for
> contact information on our offices worldwide.

More information about the Apiman-user mailing list