[keycloak-user] REST(MicroServices) authentication through SAML 2.0
Siva
siva.b at knowledgeflux.com
Wed Mar 2 07:02:56 EST 2016
Thanks Pedro. Your input gives us a good lead to plan our project execution. :)
Regards,
Siva.
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com]
Sent: 29 February 2016 22:04
To: Siva
Cc: mposolda at redhat.com; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] REST(MicroServices) authentication through SAML 2.0
----- Original Message -----
> From: "Siva" <siva.b at knowledgeflux.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, mposolda at redhat.com
> Cc: keycloak-user at lists.jboss.org
> Sent: Saturday, February 27, 2016 1:36:42 AM
> Subject: RE: [keycloak-user] REST(MicroServices) authentication
> through SAML 2.0
>
> Thanks Pedro & Marek for your valuable inputs.
>
> More questions:
>
> Based on your response for question 1 in the below mail chain, I'm
> 100% with you on the brokering scenario if we own the client layer. I
> think I've not explained my scenario and questions very well in the
> previous mail; let me try to rearticulate my challenges here.
>
> As I specified in the below mail ,we completely own the business
> systems(Server side) which will have a client UI. But the UI layer is
> loosely coupled through REST(microservice) for the server and client
> interaction to support dynamic client interaction(Our own[Primary]
> client UI or through business partners[Secondary] portal UI).
>
> Here there are 2 cases,
>
> Case 1:
> We bind our client UI in KC for authentication process through SAML
> 2.0(using IDP brokering). I'm clear on this process implementation ( since
> I've tested this approach in KC for simple web application).
+1, that makes sense. Now your clients can access your service layer using OAuth2.
> Case 2:
> My challenge here is encapsulating the REST endpoints of our server side
> services for the authentication & authorization process; irrespective of
> whether the request is coming from our own UI client or from business
> partner client; it's going to bring the token for authentication &
> authorization process (if we assume the client has received the SAML 2.0
> tokens from their respective IDP[authorization server]). when the clients
> are sharing the SAML 2.0 tokens to the REST end points how exactly this
> request need to be handled or how this token should be validated through
> the SAML 2.0 broker IDP configured in KC? This is where I'm puzzled at and
> I'm looking for your support to crack this issue.
>
> As you have mentioned, even I'm not personally positive on using the
> SAML 2.0 for REST security; but unfortunately the enterprises which we
> work with doesn't support any other protocols and we are left with no choice here.
The broker can't help you here. Case #2 is more about authorization, where you need to build a security context based on an existing token and use that to access your protected resources (business layer).
Like I said, there is that SAML 2.0 profile, which would provide a better an standardized security design. In this case, your protected resources would be protected by a single bearer token format, eg.: access_token.
Another thing you can do is customize the KC adapter to support both types of bearer tokens: SAML assertion or OAuth2 access_token. In this case, you would need to implement the necessary validations around the SAML assertions that you trust and keep the contract with your application intact regarding how you obtain the necessary claims to perform authorization checks.
>
> Your comment in the below mail chain : " An interesting solution would
> be the Security Assertion Markup Language (SAML) 2.0 Profile for OAuth
> 2.0 Client Authentication and Authorization Grants [1]." If this is
> the only solution for case 2, do we have any plan on when exactly this
> will be implemented in KC?
That I'll leave to Stian :) He is the best person to answer that.
>
> Regards,
> Siva.
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: 27 February 2016 06:37
> To: Pedro Igor Silva; Siva
> Cc: keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] REST(MicroServices) authentication
> through SAML
> 2.0
>
> On 26/02/16 14:45, Pedro Igor Silva wrote:
> >> >2) Does keycloak support Apache karaf container? I couldn’t find
> >> >any adapter for this under SAML adapter category.
> > I don't think so, but someone can give you more input on that.
> >
> We have Fuse/karaf adapters and also the examples for them, but that's
> all related to OIDC. It mostly leverages our OIDC Jetty adapter. See
> docs [1] and examples distribution (examples in "fuse" folder).
>
> We have SAML Jetty adapter, so there might be a possibility to inject
> the SAML adapter to jetty in similar ways like we're doing for OIDC...
>
> [1]
> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.htm
> l#fuse-adapter
>
> Marek
> ======================================================================
> ===========================
> -----Original Message-----
> From: Pedro Igor Silva [mailto:psilva at redhat.com]
> Sent: 26 February 2016 23:45
> To: Siva
> Cc: keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] REST(MicroServices) authentication
> through SAML
> 2.0
>
> Hi Siva,
>
> Some comments inline.
>
>
> ----- Original Message -----
> > From: "Siva" <siva.b at knowledgeflux.com>
> > To: keycloak-user at lists.jboss.org
> > Sent: Thursday, February 25, 2016 10:01:15 PM
> > Subject: [keycloak-user] REST(MicroServices) authentication through
> > SAML 2.0
> >
> >
> >
> > Hi Experts,
> >
> >
> >
> > I’ve got scenario, seeking your valuable inputs to take this in
> > right direction.
> >
> >
> >
> > My application is complete server side solution which has 6
> > different modules and it expose only the REST(Microservices) end
> > points(5 modules are hosted in tomcat 8 container and 1 is hosted in
> > Apache Karaf [OSGI bundle] ) to the external world ; which will be
> > accessed by different enterprise and they need to integrate their
> > SAML 2.0 IDP for authentication.
> >
> >
> >
> > These Microservices end points could be integrated with their
> > existing portals or could be integrated with their existing mobile
> > app applications, in some scenario’s it could be an exclusive client
> > application built to consume our REST end points which could
> > potentially be a browser based and Mobile app.
> >
> >
> >
> > The challenge here is, for now we could use only SAML 2.0 based
> > authentication since not all the organizations support OIDC/OAuth2.0
> > and as well our application could be flexible enough to be
> > integrated with the existing client portals which uses SAML 2.0 authentication.
> >
> >
> >
> > We are planning to use keycloak as IDP broker to secure our endpoints.
> >
> >
> >
> > Questions :
> >
> >
> >
> > 1) Can this be achieved in keycloak? If yes, could you please
> > provide some inputs on architectural directions in keycloak; like
> > should all the modules need to be configured under 1 relam and need
> > to have a separate brokering relam?
>
> I don't think that brokering is the best solution to address your
> requirements. If I understood your problem correctly, the clients
> trying to access your APIs belong to your partners and not you.
> Brokering is useful when you own the clients and want to create an
> indirection layer in order to integrate with external identity
> providers (pretty much the inverse of your use case). Or even during a
> migration plan when you already have some investments on SAML and want
> to gradually adopt OpenID Connect for new deployments.
>
> In your case, what you need is something that can utilize an existing
> trust relationship in order to give to your clients the proper
> security token to access your APIs.
>
> >
> > 2) Does keycloak support Apache karaf container? I couldn’t find any
> > adapter for this under SAML adapter category.
>
> I don't think so, but someone can give you more input on that.
>
> >
> > 3) For REST style endpoints, how should the user credential/Token
> > details need to shared? Any example links? kerberos is not a
> > complete solution here, since it need to work on all the
> > devices(Desktop,Laptop & handheld).
>
> Well, there is no sharing of user credentials, but security tokens.
>
> >
> > 4) For the REST based solution, can the application completely rely
> > on keycloak for the session management, after the first time the
> > user is authenticated?
> >
> >
> >
> > Any inputs on this will be highly valued.
> >
>
> An interesting solution would be the Security Assertion Markup
> Language
> (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and
> Authorization Grants [1]. Very useful when a client wishes to utilize
> an existing trust relationship, expressed through the semantics of the
> SAML Assertion, without a direct user approval step at the authorization server.
>
> But, IIRC, that spec is not yet supported in KC.
>
> I've also seem some people using SAML assertions to access RESTful resources.
> Personally, I don't think it is a good approach, since there is no
> SAML binding (standard) targeting RESTful resources.
>
> There is also the SAML ECP profile, which we added recently. However,
> it is targeted for specific use cases where you need to issue a SAML
> Assertion based on some user credentials (so you must own the users,
> not your case I think). It also provides some very basic support for
> the SP side of things, but I don't think it can help you either.
>
> [1] https://tools.ietf.org/html/rfc7522
>
> >
> >
> > Regards,
> >
> > Siva.
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
More information about the keycloak-user
mailing list