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
Related
If i host my Identityserver4 and the Api in the same Asp.net Application.
What will be used for authentication for the API Controllers?
The Cookie from Identityserver or the token which i get from the oidc-client in my SPA application?
I my tests i can access the API, also if i didn't send the token within the angular http reqeuest as long as i have the Cookie...
But is this a correct and save way???
The MVC Controllers for Identityserver are protected with ValidateAntiforgeryKey, but not the API Controllers.
Does it make sense to host both in the same Application???
Edit:
In Details, the API is used for managing the IdentityServer.
CRUD Operations for Clients, Users, Resources,...
For example:
The IdentityServer is reachable at http://localhost:5000
I want build an Angular2 SPA Admin UI which is available at http://localhost:5000/admin
The reason for mentioning ValidateAntiforgeryKey is, because if i only use Cookie Authentication for the CRUD API i should also protect these API'S with ValidateAntiforgerKey, or?
It sounds like your API and Identity Server are two separate concerns and should be handled as two separate apps. This makes it a lot easier to maintain.
You need to set up an ApiResource and a Client where you add the ApiResource as an AllowedScope in your Identity Server configuration.
Then in your API app, you must add add the authentication middleware UseIdentityServerAuthentication.
The details are explained here:
http://docs.identityserver.io/en/latest/topics/apis.html
I can see you are mentioning ValidateAntiforgeryKey. This attribute is not used for protecting against unauthorized users, but to make sure form data is being posted from legitimate forms.
I am writing some Java REST APIs which will be invoked from Web Hook configured through JIRA administration console. But, I do not see any way to add authentication header while configuring web hook in JIRA.
Without header, there is security concern in the sense that any one can invoke my Java REST APIs.
Could someone please suggest here how to add custom headers in web hook with possibly some example. I have already gone through Atlassian develper documentations but do not find any solution over there.
Adding a username and password to the Jira Cloud webhook URL e.g.
http://user:password#mycallbackurl.com
is ignored by Jira Cloud unfortunately. It seems that other Atlassian products do provide the ability to set a header / provide username and password for basic authentication.
Also see:
https://jira.atlassian.com/browse/JRA-31953
https://answers.atlassian.com/questions/12270170/where-does-the-webhook-arrive-from.
You basically have two options:
You can add an API key or some kind of secret to the webhook URL. The disadvantage is that the secret could show up in your web server logs.
Don't trust the webhook POST body (JSON) and pull the information from the API.
Adding the Atlassian server IPS to a white list would also make sense:
https://confluence.atlassian.com/cloud/database-and-ip-information-744721662.html#DatabaseandIPinformation-IPAddressrange.
Although it doesn't completely eliminate attack vectors since attacks can also come from another Jira cloud environment.
There is no support to add extra header in JIRA webhook configuration. So, authentication header can not be added in webhook configuration.
To do the authentication, one way is
1) Retrieve User information from incoming JSON
2) Make JIRA REST API call to check user's authenticity
3) Deny or allow further processing based on result
I've been trying to integrate OAuth2 authentication in my drf application. Given I don't yet need a front-end for my app, I was using the browsable API. DRF and the OAuth2 provider package are supposed to work together without much configuration, as explained in the tutorial.
I should mention that all the steps from the tutorial are working (so I can access the app from the command line) but when I try to do it from the browsable API, I don't see any request for an access token or anything like that.
I think that DRF does not actually provide the flow for the front-end part of authentication by OAuth2, but I was just wondering if someone managed to make it work (because for now I am using SessionAuthentication).
Thanks.
OAuth2, unlike basic authentication and cookie-based authentication, does not easily work within the browser. When authenticating requests, it relies on the Authorization header being present (with the OAuth type) and there is no way using a browser to easily fill that in.
Session authentication relies on cookies, which most browsers easily support, and is recommended for interacting with APIs that are on the same domain as the front end.
Basic authentication also relies on the Authorization header, but uses the Basic type which is supported by most browsers.
I am struggling with understanding how to implement the following in Web API 2's OWIN pipeline.
I am building an application that will allow users to log in with several third-party identity providers such as Facebook, Twitter, LinkedIn, etc. However, I want the authentication step to be performed entirely client-side. For example, Facebook provides developers a snippet of markup and JavaScript that perform the authentication within the browser, resulting in a Facebook access token--all without any calls to my API.
The Web API templates that ship with Visual Studio 2013 all seem to assume that the API itself is in charge of the authentication flow. I have successfully gotten this style of authentication working, but in my opinion it is not the responsibility of the API to perform this work.
Here is the approach I have been trying to implement (so far unsuccessfully):
Provide endpoints like /authenticate/facebook that accept the appropriate access token and return a JWT with "decoded" claims if the access token is valid. This JWT would have similar claims regardless of the third-party identity provider. For Facebook, I think this involves a call to Graph API's /me endpoint.
Store the JWT in the browser's localStorage for subsequent API calls
Send the JWT in the Authorize header for each API call
Avoid cookies if at all possible
My questions:
Is this an appropriate way to handle third-party authorization?
Should the JWT's expiration match the third-party access token's? I assume yes, but I want to be aware of any caveats here.
Where and how do I store the third-party access tokens for use on subsequent API calls? Do I include them with the JWT?
Is there a template I can use out-of-the-box, or perhaps an online resource that implements authentication and authorization in this way? I don't understand how to use Web API's many classes and features to implement this.
I have this mostly figured out now. I believe my architecture choice is the correct one after much research, specifically into the so-called "assertion flow." I am using Thinktecture's Identity Server 3 project to act as my STS. I am using a custom implementation of ICustomGrantValidator to perform the validation of the Facebook access token and conversion to claims.
I have a web service built with WebAPI that accepts JSON requests and responds accordingly. The core architecture is built but there isn't any authentication/authorization.
After a lot of googling and poking around sample projects, I'm not sure where to start. I've found a ton of material from 2008 and 2009 but not a whole lot of recent guides/workflows for WebAPI / single page apps. I think the workflow should be as follows:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
Let the user log in / register: How is this data encrypted/decrypted? Surely I can't be sending passwords over the wire... is this where SSL comes in?
Provide them with access to what they have rights to access: I think I got this - I can just authorize in the controllers on a per-request basis.
Any info would be awesome.
Basically you need a token based authentication or authorization.
If you are referring to the ASP.NET WebAPI, the following project will be a great place to start:
http://thinktecture.github.com/Thinktecture.IdentityModel.45/
Even if you are not using ASP.NET WebAPI, the following video is a great introduction on how to provide authentication/authorization on RESTful web services:
http://vimeo.com/43603474
To answer some of your questions:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
You can use a cookie but I normally use the header in order to avoid common XSRF attacks. Cookies are automatically included whenever a http request is sent from the browser.
is this where SSL comes in?
Yes. If you are going to go ahead with the token based approach, you can use a separate server (Identity Server) to do the authentication for you.
JavaScript clients are unique. Do you have the Web API and the page serving up JavaScript in the same domain? If not, you have same origin policy restrictions. If you have the same Web application hosting the web pages and Web API, you can use forms Authn. In that case, you don't need to send the cookie containing the authentication ticket yourself from JavaScript. Browsers do that for you and that is the cause of XSRF problem. You have to be careful about JavaScript sending credentials that the end user is not supposed to know. If JavaScript knows something, any intelligent end user can get to that knowledge. OAuth 2.0 implicit grant could be a good choice. The end user enters the credentials (password) in the authorization server which issues an access token. JavaScript gets the token and presents it to the web API but it will never have access to the credentials.