7:01 p.m.
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?
2) Does keycloak support Apache karaf container? I couldn't find any
adapter for this under SAML adapter category.
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).
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.
Regards,
Siva.
7:45 a.m.
Hi Siva,
Some comments inline.
----- Original Message -----
From: "Siva" <siva.b(a)knowledgeflux.com>
To: keycloak-user(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:37 p.m.
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.html#f...
Marek
10:36 p.m.
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).
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.
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?
Regards,
Siva.
-----Original Message-----
From: Marek Posolda [mailto:mposolda@redhat.com]
Sent: 27 February 2016 06:37
To: Pedro Igor Silva; Siva
Cc: keycloak-user(a)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.html#f...
Marek
=================================================================================================
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: 26 February 2016 23:45
To: Siva
Cc: keycloak-user(a)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(a)knowledgeflux.com>
To: keycloak-user(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
6:04 a.m.
----- Original Message -----
From: "Siva" <siva.b(a)knowledgeflux.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>, mposolda(a)redhat.com
Cc: keycloak-user(a)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@redhat.com]
Sent: 27 February 2016 06:37
To: Pedro Igor Silva; Siva
Cc: keycloak-user(a)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.html#f...
Marek
=================================================================================================
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: 26 February 2016 23:45
To: Siva
Cc: keycloak-user(a)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(a)knowledgeflux.com>
> To: keycloak-user(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
6:02 a.m.
Thanks Pedro. Your input gives us a good lead to plan our project execution. :)
Regards,
Siva.
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: 29 February 2016 22:04
To: Siva
Cc: mposolda(a)redhat.com; keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] REST(MicroServices) authentication through SAML 2.0
----- Original Message -----
From: "Siva" <siva.b(a)knowledgeflux.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>, mposolda(a)redhat.com
Cc: keycloak-user(a)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@redhat.com]
Sent: 27 February 2016 06:37
To: Pedro Igor Silva; Siva
Cc: keycloak-user(a)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@redhat.com]
Sent: 26 February 2016 23:45
To: Siva
Cc: keycloak-user(a)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(a)knowledgeflux.com>
> To: keycloak-user(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
3207
days inactive
3212
days old
5 comments
3 participants
participants (3)
-
Marek Posolda -
Pedro Igor Silva -
Siva