I have extended the Keycloak REST API to add my REST endpoint to the URL {{server}}/auth/realms/{{realm}}/myApi using mechanisms described in the Keycloak documentation and it works fine.
However, my api is an internal company one and my IT asked me to put it behind the /admin (for legitimate security reasons) and thus I should have my api here : {{server}}/auth/admin/realms/{{realm}}/myApi
Is it possible to add endpoints "behind" to the /admin ?
I currently use the (outdated) version 15.0.2 of Keycloak with WildFly
Thank you
Related
We have our own authentication server developed in NodeJs, which acts as identity provider for users. So We are looking for how we can integrate it with Kibana-opendistro.
The security responsibility lies with the security plugin, so most of the configuration should be made there.
Opendistro Security provides support for a couple of authentication backends that you can refer here https://opensearch.org/docs/latest/security-plugin/configuration/configuration/. You can configure the security plugin based on the authentication mechanism used.
Alternatively, there is this concept of injected user where the authentication is completely handled by another service fronting the security plugin. Though I did not find documentation on this, you can refer to the code here https://github.com/opensearch-project/security/blob/565f47e804ec03aeeba02ca8def563b91307fcc7/src/test/java/org/opensearch/security/test/plugin/UserInjectorPlugin.java
I have two Spring Boot web applications. Both applications have different databases and different sets of users. Also, both applications use Spring Security for authentication and authorisation which works properly.
At any given point I will have one instance of the first application running and multiple instances of the 2nd web application running.
I want to expose REST APIs from 1st web application (one instance running) and be able to use that REST APIs from 2nd web application (multiple instances running).
How do I make sure that REST APIs can be accessed securely with proper authentication and by instances of the 2nd applications only.
If you could change your security, I would recommend you to use OAUTH2. Basically it generates a token that is used in your APP2 instances to make the API calls.
You can see more here.
https://spring.io/guides/tutorials/spring-boot-oauth2/
http://websystique.com/spring-security/secure-spring-rest-api-using-oauth2/
But if you can't change your APP's security, you can continue using your current schema. In the APP1 you can create an user for the API calls, this user only has access to the API services. In your APP2 you need to store the credentials to access the APP1. Finally you do login into APP1 and invoke the API using HTTP client, you can use Spring RestTemplate or Apache HttpComponents Client.
SSL based authentication could be an option, if you seriously thinking about the security aspects.
Assume that you REST api exposed by App 1 is over HTTPs, then you can configure the App 1 to ask the client to give their SSL/TLS certificate when they try to access this REST API (exposed by App 1).
This will help us identify that the client is indeed a client from app 2.
Two More Cents:
In case if your App 1 REST API calls needs load balancing, NGINX should be your chose. The SSL client certificate based authentication can be offloaded to NGINX and Your Spring boot app no more worry about the SSL related configurations.
The solution we went with was to secure both using an OAuth2 client_credentials workflow. That is the OAuth2 flow where clients request a token on behalf of themselves, not a calling User.
Check out Spring Cloud Security
1) Secure your services using #EnableResourceServer
#SpringBootApplication
#EnableResourceServer
public class Application ...
2) Make calls from one service to another using an OAuth2RestTemplate
Check out Resource Server Token Relay in http://cloud.spring.io/spring-cloud-security/spring-cloud-security.html which will specify how to configure an Oauth2RestTemplate to forward on security context details (token) from one service to another.
3) Service A and Service B should be able to communicate using these techniques if they are configured using the same Oauth2 Client and Secret. This will be configured in the applications' application.properties file, hopefully injected by the environment. Oauth2 Scopes can be used as role identifiers. You could therefore say that only a Client with Scopes (api-read, api-write) should have access to Endpoint A in Service A. This is configurable using Spring Security's Authorization configuration as well as #EnableGlobalMethodSecurity
We are implementing RESTful service and the entire backend application using Vert.x. These API's are consumed by a hybrid mobile app (developed using Ionic / angularjs). We are using Keycloak for user management and also authentication and authorization on the app.
My question is, how can I use Keycloak to also protect (authenticate and authorize for the same set of users) my RESTful service access which is implemented using Vert.x. Any example implementation would be very useful.
We wrote a custom Vert.x auth provider using the Keycloak core library to solve this exact problem (the Vert.x JWT library doesn't work with the Keycloak JWT tokens - arguably we should have improved the Vert.x library instead). I'll see if I can get permission to open source the library.
So, if i understand correctly, you need one authentication entry point for user in mobile app and in REST service. If i am right, you can use JWT. When user will authenticate with Keycloak he will receive jwt with roles and user information. This token you can put into request for REST service and your Service will know who is the user and what roles he have. Please see https://jwt.io/
I've been dropped into a hot potato project...an external entity produced a SOA architecture and we need to implement it now.
Using Drupal as a CMS and starting point of the architecture.
Here's what I think we need to do:
Authentication server
People register through the drupal site. We'd like to reuse the identity created for other (future) services, through a REST API
a) Can I add users to WSO2 Identity Server via a (REST) API?
b) Can I query WSO2IS to authenticate users via a (REST) API (creating a SSO env)?
c) Can I create re-usable profiles in WSO2IS, accessible through a (REST) API?
d) Can I authenticate drupal access via WSO2IS through a (REST) API?
e) Can I query the XACML policies via a (REST) API so that access to a requested service can be evaluated?
Other REST APIs we're going to build would use the OAuth functionality of WSO2
The architecture mandates each an authentication, a profiles and a policy (authorization) with XACML (...) module. The alternative is to build it all ourselves but I think we won't have the time for this, but I need to understand if we can do the above mentioned things to make a decision if WSO2IS is a good choice for our needs.
I have read the available documentation, browsed the help system, installed WSO2IS and checked out the interfaces, but couldn't find the responses. The only thing I managed to do is create the OAuth server.
Please find my answers..
a) Yes.. WSO2 Identity Server supports SCIM which is the standard approach for identity provisioning. Also there are web service APIs, that expose user management functions. You can front those web service API using WSO2 APIM and can expose as REST API.
b) Yes.. Apart from REST and web service API, Identity Server supports for authentication methods such as SAML2SSO, OpenID, IWA and so on.
c) Yes.. same as a) you have both options SCIM or Web service API fronted with APIM
d) There is an authentication framework in the WSO2IS, that users can be authenticated with different server.. Basically WSO2IS can act as federated IDP that application knows only to talk to WSO2IS.. WSO2IS can authenticate users from any other IDP, It can be drupal as well
e) Yes.. XACML is supported by WSO2IS... Its PDP API has been exposed via web service API.. but not as a REST API.. but as i mentioned earlier, you can expose it as REST using APIM. However REST support for XACML would be available with the further release
We are designing security for a green field project with a UI web module (Spring MVC) - the client, and a RESTful services web module (CXF) - the server, to be deployed as separate war files in the same Websphere app server. The system should be secured with Spring Security, authenticating against LDAP and authorizing against a database. We have been looking for the best solution to share the security context between the 2 apps, so a user can authenticate in the web UI and invoke its AJAX calls to the secured RESTful services. Options found:
OAuth: seems overkill for our requirements, introduces a fairly complex authentication process, and reportedly some enterprise integration issues
CAS: would amount to setting up an enterprise SSO solution, something beyond the scope of our engagement
Container-based (Websphere) security, although not recommended by Spring Security, and we're not clear if this could provide a solution to our specific needs
We're looking for a simpler solution. How can we propagate the Security Context between the 2 apps? Should we implement authentication in the UI web app, then persist sessions in the DB, for the RESTful services to lookup? Can CXF provide a solution? We read many threads about generating a 'security token' that can be passed around, but how can this be done exactly with Spring Security, and is it safe enough?
Looking forward to any thoughts or advice.
You want to be able to perform the REST web services on the server on behalf the user authenticated in UI web module.
The requirements you described called SingleSignOn.
The simplest way to do it is passing the HTTP header with the user name during REST WS calls.
(I hope your REST client allows to do it).
To do it in secure way use one of the following:
Encrypt the user name in REST client and decrypt it in REST server
Ensure that the header is sent from the local host (since your application deployed on the same container)
Therefore, protect both application using SpringSecurity authenticate against LDAP.
In the first application (Rest Client) use regular Form Authentication
In the second application (Rest Server) add the your own PreAuthenticatedProcessingFilter:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#d0e6167
Edited
The “Authentication” is the process of verifying of a principal’s identity.
In our case both REST Client (Spring MVC application) and REST server (CXF application) verify an identity against LDAP. LDAP “says” OK or Not. LDAP is a user repository. It stateless and does not remember the previous states. It should be kept in applications.
According to my understanding, a user will not access directly to REST server – the user always access REST Client. Therefore, when the user access REST Client he/ she provides a user name and a password and REST Client authenticate against LDAP. So, if REST Client access REST server the user is authenticated and REST Client knows his name.
So, if request come to REST server with a user header name - REST server for sure knows that the user was authenticated and it should not authenticate it again against LDAP.
(The header should be passed in the secured way as described above).
Rest Server should take the user name, to access to LDAP and to collect related user information without providing of the user password (since the user already authenticated).