Restful Web Service with Kerberos Authentication - java

Starting a new project to create a restful Web Service that requires callers to be Authenticated by Kerberos (Active Directory).
The web service will be hosted by Tomcat and I was planning to use JAX-RS with JAAS but I'm not finding much information on this, does anyone have information or experience on getting this to work?
Should I be looking at Spring and Spring Security instead?


Apache provides good documentation for using JAXRS with kerberos. Here is the link:
http://cxf.apache.org/docs/jaxrs-kerberos.html


I have the same issue. I googled extensively and not found a good answer.
The problem is that the issue has several layers and most answers point to (usually vague) solutions for only one layer.
And there is not a single complete and clear example for the end-to-end solution.
LAYERS
Client call to rest service using kerberos/windows logged in credentials.
Answers usually show how to use kerberos to authenticate but fail to say how to use it to pass the logged in credentials to the REST service.
Both Spring REST client functionality and native Java seem capable of doing this but it is not clear how.
Processing by the REST service of the authentication request by the client that is authenticating via windows/kerberos.
Spring REST service functionality appears to be the easiest way to implement it but again it is not clear how to tell the REST service to expect that authentication method.
Either forwarding the client kerberos credentials to whatever resource the REST service is trying to access, or get a success/failure and then the REST service uses kerberos/windows authentication itself (different credentials from the clients) to access a resource.
I hope this clarification of the issue helps in producing a good answer.


In Kerberos there are two severs url involved authentication server and the other ticketing server. If you go to browser console under ticketing server response parameter you can see a cookie that you can utilise to authenticate your rest api by utilising it as a request parameters.
That’s the only solution to authenticate your rest api.

Related

how to create a "https" secured REST API from a SOAP servies in java springboot

I am working on integrating a SOAP service provided by european VAT validation service VIES.
the SOAP service is hosted at following links
https://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl
http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl
I think both of them leads to pretty much same site with one being http and other https
(please let me know if there is a difference).
so I integrated the wsdl into our spring boot application and it worked fine when I tried in in my local host which was http. but as soon as I hosted it in to our live server which is https it started giving error reply.
I searched for possible reasons why it isn't working and ended up with the conclusion that the SOAP services provided by VTES works only in http sites.(let me know if I am wrong)
but when I searched for more solutions I found more sites that provide https secured REST application that uses same SOAP service (https://vatlayer.com/) . We tried to reason with our client to purchase one of those since they only allow a limited number of free VAT validations, but they are not happy with that,
but it got me thinking since they can built a https secured REST API with this thing it means I can do that to. so I searched for a solution but couldn't find any, can anyone please give a insight into it about how it is done.
Thanks and regards.

If you are calling the link from the web browser(client side) and if your live web application runs on HTTPS, then you should also call the SOAP service with HTTPS or otherwise the browser will see it as violating the Same Origin Policy and will block your request.

How to create Web Authentication for Corda RPC Users?

Using the webapp, which uses corda-webserver, how to implement authentication mechanism for RPC Users?
RPC Users mentioned in the configuration file.
And perform role based actions(Only accessible flows).
I could only find detail about authenticating RPC Users through ClientRPCOps, but couldn't find anything about web based authentication.

Web authentication is not directly related to Corda. Connecting to a node via rpc requires authentication. Anything past that is not Corda's problem.
If you want to setup web authentication, then you should look into how frameworks like Spring or Ktor handle these scenarios. Corda is not web based by default and requires integration into a "web server" application to be web-enabled.

Different ways to secure RESTful Web service in java used by one or two clients only?

I have created REST web service in java but need to secure it so that only the authorised clients should be able to access the service. I have never implemented security before. Hence I have no idea where to start to be honest. Do I need to implement any token based security where client need to provide the token in the header of request and I need to verify on my end ?

As RESTful Web Services work with HTTP URL Paths, it is very important to safeguard a RESTful Web Service in the same manner as a website is secured.
For understanding of importance of security consider the following links:
http://howtodoinjava.com/security/restful-web-services-security-guide/
How to secure RESTful web services?
While for Implementation using Spring use the given link:
https://dzone.com/articles/securing-restful-web-service

Adding Oauth 2.0 to Jersey based RESTful server

I have a Jersey based server that I want to secure with OAuth 2.0. There are two paths that I've seen as common:
Oltu - Is compatible with Jersey and seems to be supported, although not as well as Spring Security. This 2012 question seems to suggest this is the way to go, but I want confirmation on a 2016 context so I son't implement something not as well supported anymore.
Spring Security - It seems to be very popular, but this path implies changing the server into a Spring based MVC. I don't know if that is something recommendable based on the benefits of using something as widely supported as Spring and the cost of the refactoring.
With support I mean a project that is in continous development, well established community with tutorials, materials and some libraries for clients (web, mobile, server) already available.
Which one is a stronger option? Is there another option or options?
In any case. Is there a good reference material or tutorial to start implementing this?
UPDATE
After few hours of reading and understanding about both the OAuth Providers I had mentioned, I feel Apache Oltu's documentation did not guide me much as there are key components that aren't documented yet, but an example gave me a better picture on how Oltu must be implemented. On the other hand, going through Spring Security's material I got to know that it can still be built on a non-Spring MVC based java project. But there is a limited exposure of implementations/tutorials on Spring Security on a non-Spring based project.
Another approach:
I came up with an architecture that might be more stable and would not care about the implementation details of the inner server(the one already implemented using Jersey). Having a server that is dedicated for security purpose (authorizing, authenticating, storing tokens in its own database, etc) in the middle that acts like a gateway between the outside world and the inner server. It essentially acts a relay and routes the calls, back and forth and ensures that the client knows nothing about the inner server and both the entities communicate with the security server only. I feel this would be the path to move forward as
Replacing with another security provider just means plugging out the security server implemetation and adding the new one.
The security server cares nothing about the inner server implementation and the calls would still follow the RESTful standards.
I appreciate your suggestions or feedbacks on this approach.

Apache Oltu supports OpenID Connect but its architecture is bad. For example, OpenIdConnectResponse should not be a descendant of OAuthAccessTokenResponse because an OpenID Connect response does not always contain an access token. In addition, the library weirdly contains a GitHub-specific class, GitHubTokenResponse.
Spring Security is famous, but I'm afraid it will never be able to support OpenID Connect. See Issue 619 about the big hurdle for OpenID Connect support.
java-oauth-server and java-resource-server are good examples of Jersey + OAuth 2.0, but they use a commercial backend service, Authlete. (I'm the author of them.)
OpenAM, MITREid Connect, Gluu, Connect2id, and other OAuth 2.0 + OpenID Connect solutions are listed in Libraries, Products, and Tools page of OpenID Foundation.
**UPDATE** for the update of the question
RFC 6749 (The OAuth 2.0 Authorization Framework) distinguishes an authorization server from a resource server. In short, an authorization server is a server that issues an access token, and a resource server is a server that responds to requests which come along with an access token.
For a resource server, API Gateway is one of the recent design patterns. Amazon, CA Technologies, IBM, Oracle and other companies provide API Gateway solutions. API Gateway architecture may be close to your idea. Some API Gateway solutions verify access tokens in their own ways (because the solutions issue access tokens by themselves) and other solutions just delegate access token verification to an external server (because the solutions don't have a mechanism to issue access tokens). For example, Amazon API Gateway is an example that delegates access token verification to an external server, which Amazon has named custom authorizer. See the following for further information about custom authorizer.
Introducing custom authorizers in Amazon API Gateway (AWS Blog)
Enable Amazon API Gateway Custom Authorization (AWS Document)
Amazon API Gateway Custom Authorizer + OAuth (Authlete article)
If an authorization server provides an introspection API (such as RFC 7662) that you can use query information about an access token, your resource server implementation may be able to replace (plug-out and add) an authorization server to refer to comparatively easily.
For an athorization server, gateway-style solutions are rare. It's because such a solution must expose all the functionalities required to implement an authorization server as Web APIs. Authlete is such a solution but I don't know others.

I think, it's far simplier to use the oauth connectors that are implemented inside jersey itself!
Have you considered using jersey own OAuth (already linked inside jersey) server / client ?
https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/security.html#d0e13146
Please take a look to :
16.3.2. OAuth 2 Support
hope helped. :)

Working with REST API Calls while Using Spring Security Core PlugIn

I am currently working on Grails Application where I have REST API using jaxr PlugIn. The scenario is that there is a Third Party who says that give us a URL and we will send you the notifications on that URL.So I created a REST API with post method. So I can send data using this post method. So,I gave this URL to that third party which now sends me notifications over that URL. And in the body of that POST method in my REST API gets the notification and do what I want to.
So, I used Spring Security Core to authenticate my other features of application. And I wasn't intended to secure this REST API that I implemented using Jaxr PlugIn. But after using that Spring Security Core plugin my Rest API stopped working as it has restricted this REST API too. I tested it on my machine too and send post requests but this plugin is not allowing me to make request due to authentication issue.
Please guide me that what I should do in this scenario? I don't want to secure my REST, can I proceed with this?
Thanks for your precious time :)

With Spring security you define urls that are secured. Specify correct url patterns and it should be ok.

Categories

Resources