We are building a Restful service using Grails framework and are providing security for it using Spring Security plugin. I wanted to check with you all on best approach to take when you want to authenticate using Custom Authorization header. More on this approach can be read here
Custom HTTP Authorization Header
In my case, client id and secret is stored in Ldap and header comes with SHA1 encryption. What would be the best approach to implement this using Spring Security?
I have asked same question in Grails mailing list too.
Any insight would be helpful. Thanks.
~Abhi
You have to implement your own Filter, Authentication Provider and Authentication token (to pass data to your Provider).
See:
what is securty filter chain - http://static.springsource.org/spring-security/site/docs/3.0.x/reference/security-filter-chain.html
authentication providers - http://static.springsource.org/spring-security/site/docs/3.0.x/reference/core-services.html#core-services-dao-provider
how to register your filter into Spring Secutory Core plugin - http://grails-plugins.github.com/grails-spring-security-core/docs/manual/guide/16%20Filters.html
and, if you need an example, take a look at some existing authentication subplugins for Spring Security Core - http://grails.org/plugin/spring-security-core
List item
If you are using basic authorization header, then following configuration works for you in context-security.xml file.
< http auto-config="true" use-expressions="true" pattern="/project/api/**">
< intercept-url pattern="/**" access="isFullyAuthenticated()" requires-channel="${security.requires.channel}" method="POST"/>
< custom-filter ref="basicAuthenticationFilter" position="PRE_AUTH_FILTER"/>
< /http>
< beans:bean id="basicAuthenticationFilter" class="org.springframework.security.web.authentication.www.BasicAuthenticationFilter">
< beans:property name="authenticationManager" ref="authenticationManager" />
< beans:property name="authenticationEntryPoint" ref="authenticationEntryPoint" />
< /beans:bean>
I have used same approach for rest services But you need to be careful that whatever scheme you use for encoding username and password, same scheme you should use in filter for decoding 'Authorization' header information. If you are using some custom scheme for encoding 'Authorization' header, then you need to extend 'BasicAuthenticationFilter' and provide appropriate decoding of 'Authorization' header
Related
I want to develop an authentication mechanism for 3rd party applications using keycloak initial access tokens. But I want to do this only by using the access tokens that I have generated in the keycloak. For example, I will give a generated token to the user and allow him to log into the application. Is this possible? How can i do that?
Initial Access Token
First, I'm not sure it is a good idea to use "initial access token" for authorizing requests to your own resources. It might even not be allowed. As per the doc:
An initial access token can only be used to create clients
Second, don't use keycloak libs for Spring as suggested in other answer. It is very deprecated.
Last, a REST API secured with Oauth2 is a resource-server (and not a client). As so, the dependency should be spring-boot-starter-oauth2-resource-server. Spring doc is pretty extensive on the subject. You can also have a look at those tutorials for resource-server configuration (and OAuth2 definitions).
Once the resource-server (Spring REST API) is configured, clients will have to authorize their requests as normal for OAuth2: provide with an Authorization header containing a Bearer access-token (a JWT issued by Keycloak to the client with one of standard flows: client-credentials or authorization-code depending you need to authorize the client itself or a user behind it).
Edit
I might have misunderstood your need. If what you want is having new clients register themself programmatically on your Keycloak instance, then those clients will just issue a REST request to Keycloak server API with the "initial access token" in Authorization header as normal.
Once registered, those clients will be able to call you resource-servers as described in my initial answer.
I have created a Twitter-developer account and also a project and an app to be able to invoke web services endpoints.
I would like to know if anyone has ever managed to successfully retrieve expected response from the endpoints, and in that case, what authentication methods is the simplest and most effective to use and in what order?
Thank you for your help and advice
As per Twitter API documentation the possible methods are in:
OAuth 1.0a
OAuth 2.0 Bearer Token
Basic authentication
The latter one is the easiest to implement as all you need to do is to add HTTP Authorization Manager and provide your credentials there and JMeter will automatically add the relevant Authorization header to all your HTTP Request samplers
More information: How to Use HTTP Basic Authentication in JMeter
I'd like to create a new application based on HIPPO CMS and expose my custom business REST API in HIPPO HST(Delivery) application. On the other hand, application implemented with AngularJS will consume these REST API.
Right now I don't understand which authentication mechanism(out of the box with HIPPO CMS) should be used in order to get secure access from AngularJS application to secured Rest endpoints in HST.
Could you please describe how it should work and what an approach in HIPPO CMS should be used for this purpose ?
We have documentation on that. Default it is protected with basic authentication against repository users. You can also define a custom CXF JAXRSInvoker.
From our docs:
"By default the RepositoryJaxrsService will configure every REST endpoint to be basic authenticated against the Hippo Repository, using the provided username and password to (only) login to the repository. The authentication (and authorization, see further below) handling is configurable and overridable, per REST endpoint when using a CXFRepositoryJaxrsEndpoint builder. The authentication, and optional authorization, is handled by a custom CXF JAXRSInvoker providing pre/post processing of a request invocation. The default authentication is provided by the AuthenticatingRepositoryJaxrsInvoker, which enforces a repository login before proceding with the request handling. The CXFRepositoryJaxrsEndpoint builder allows configuring a custom JAXRSInvoker,"
I suggest you reference the documentation on the onehippo.org site. It has the latest information as well as historical references for previous versions.
http://www.onehippo.org/library/concepts/hippo-services/repository-jaxrs-service.html
I'm planning an API and I haven't found any information about where the access token should be placed in the response. I'm interested in the case where I'm providing the access token. What is the best practice to send the token to the clients (from the backend service)?
Should it be sent to clients in the Header or in the Body of the answer?
You should look at examples and see what others do. For example, Facebook, Twitter, Google, Amazon... and all those popular PaaS services exposing a REST API all use OAuth2 as authentication mechanism:
In OAuth2 you'll see the specification requires to send the generated token to the client in the body of a json response: https://www.rfc-editor.org/rfc/rfc6749#section-5 . But you can also see how Google and other vendors extend this mechanism so it can be sent as a callback url param, for example (Check out https://developers.google.com/identity/protocols/OAuth2UserAgent).
Once you get the authorization token you put it on the Authorization: HTTP header you send on your requests for accessing protected resources. They have to support this way of doing it, because it is how the OAuth2 standard specifies it https://www.rfc-editor.org/rfc/rfc6749#section-7
If you want to tinker a little bit more with oauth, check out https://developers.google.com/oauthplayground
(OAuth is pretty much the same thing.)
They usually also extend the Authorization header mechanism to allow the token to be provided as a GET/POST parameter in the url or the body of the response, respectively (For example, Facebook's Graph API also supports passing an access_token= parameter on your HTTP POST request body or GET URI). There is no way to manipulate or even read HTTP headers on a javascript browser application (see the modern fetch API and other proposals on Accessing the web page's HTTP Headers in JavaScript), so providing this functionality makes life easier for many app developers.
Another popular authentication scheme is SOAP authentication. It doesn't support tokens but it supports digest authentication, which is a similar thing. The interesting part of it is that it is not HTTP/Web based (although it is primarily used that way), so you can use it over other application protocols. It's a little more cumbersome, but you can find ready to use implementations for both server and client.
You can also use digest authentication over HTTP without SOAP. It is also based on Authorization: headers and every browser supports it. Check out https://en.wikipedia.org/wiki/Digest_access_authentication to see how the authorization headers are formed in different ways depending on the level of security you want to reach.
Some services, like redmine, allow you to use an API token (API key) instead of a session token. Then you can make basic http auth on your requests like https://whatever:yourapikey#example.com/protectedMethod, although passing of auth data on URLs is currently deprecated in favor of basic auth header, and plain passwords / static API keys should only be sent over secured SSL connections. In this case the client can have the server generate an api key using a web interface or a rest api (so the generated key will be passed as a JSON response). This method may not be such a good idea, though: Check http://talks.codegram.com/http-authentication-methods#/intro if you want to know why, and also this question discussing where to put them: Where should I place API keys in REST API calls?
I have a web api application which implements the Resource Owner Password flow from OAuth specification. Everything works correctly.
Actually I configure everything in my WebApiConfig class by using an Authentication filter like this
// Configure Web API to use only bearer token authentication.
config.SuppressDefaultHostAuthentication();
config.Filters.Add( new HostAuthenticationFilter( OAuthDefaults.AuthenticationType ) );
As some of my customer asked for a different method of authentication I am evaluating to add a couple of features to my services but stil did not have clear how those features can work together.
In particular I cam across a link which explain in very easy words how to implement a HMAC authentication in web api.
Can I implement this authentication method and let the client to choose which one he want to use? Do they can cohesist together?
Yes, your web api service can send back multiple schemes in the WWW-Authenticate challenge. In your case it can send back 'bearer' and 'hmac' for example.
See also this question for more info on using multiple schemes.
BTW, it's not your web api service that supports Resource Owner Password flow. The client uses this flow to get a token from the authorization server that it can use in a bearer scheme with your service (resource server). HTH.