I have to covert a SOAP based into RESTFul application. We are using IBM websphere and LTPA token for authentication. I have 2 ideas about it.
Manually convert into restful application. (Not sure how to integrate LTPA into it)
Provide a proxy so that a restful application makes call to soap and fetch response. (Think i don't have to worry about LTPA here)
What am looking for is the easy of use for the end user, so that they don't have to construct the whole xml.
I am not sure what exactly is the role of LTPA. Are you looking for identity, authentication or authorization. If you want all then you need to think of a way to integrate LTPA and OAuth. You can use the OAuth for making the rest service secure.
You can get some more info here.
http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/
Related
I'm currently writing a hobbit project. I implemented a REST API service. It reads the authentication token from the Authorization header. Now I'm implementing the web front-end. I know I should store the token in an HTTP-Only cookie for security. However, this means the JS cannot read the token and uses it in the Authorization header when calling the REST API. The solutions I can think of are
Change the REST API, reading the token from the cookie, so the JS code can just make a request. But I've heard this is NOT a good practice.
Make a "proxy" service, translate the request by reading the cookie and filling it into the Authorization header, then forwards it to the REST API service. The web front-end calls this proxy service instead.
Which one or any other solution is the best practice?
The architecture of the system is like this
User can log into the website using either username-password approach (after registration) or a google-sign-in.
I want to know how can I implement authentication and authorization for this scenario.
Here is what I am thinking of implementing :
Have an REST API server built over NodeJS and Express.
The login and registration processes are handled by this server as well.
The authentication is done by using JWT Tokens stored in the client side. And these tokens are then used again for authorization of endpoints as well.
How much secure is this approach? And how can google sign in be added to this architecture.
And also if a seperate server for making auth requests is needed as mentioned in OAuth 2.0?
It would be better if the system remains Stateless to follow the principles of RESTFul APIs.
This post that I have written might give you some insight.
https://dev.to/ralphwjz/login-management-for-spa-and-everyone-else-12o6
The post covers Github login but if you replace GitHub with google, the rest of the flow is exactly the same.
I can answer more questions once in context
We're developing an iOS app, where the user needs to authenticate using email+password (or mobile number). Our backend is made of a couple of microservices using Akka-Http. It needs to be fast, scalable, concurrent, and the authentication+authorization should work across our multiple services.
I'm trying to figure out which authentication method to use.
Akka-HTTP currently offers Basic Auth and a partial implementation of OAuth2.
So at first we were considering Basic authentication (too simple and not enough functionality), Oauth1 (too complex), so we moved towards OAuth-2.0 because it is sort of a standard.
Then we considered AWS Cognito because it combines Oauth-2.0 and OpenID Connect which gives the authentication mechanism that OAuth2 lacks.
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
Then we realised that OAuth2 is just for authentication using a third party - when in fact we don't need a third party authentication provider - maybe we need to do it ourselves, and using Cognito is an overkill that would create extra api calls outside our microservices...
So I read a little bit about creating our own custom auth provider, using WSSE specs:
http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html
And I also found this example using Spray, but I'm sure it's not that different from Akka-Http:
http://danielasfregola.com/2015/06/29/how-to-create-a-spray-custom-authenticator/
It looks too simplified and doesn't have token expiration...
So my question is, am I missing something? What method should I chose and where can I find examples for it?
I feel like I'm going in circles, we're gonna have to write our own custom authentication provider from scratch, which kinda doesn't make sense. After all almost everybody needs authentication and it should be a standard.
I've recently been using SoftwareMill's akka-http-session library and found it simple and easy to integrate. It has support for case class based sessions, JWTs, refresh tokens with pluggable storage, using headers and CSRF tokens as well as some nice simple directives for use in routes.
My solution for user registration has been to use Keycloak, an open source server which can handle user registration and do OIDC, OAuth2 style login. It reduces the amount of code I have to write, and the code is more secure than if it rolled it myself.
I then write my application as Scala backend that's purely a JSON API and a React/Javascript rich frontend in front of that API. In this configuration the authentication is handled completely on the front-end (and can be done in your iOS client). The front-end app redirects the user to Keycloak and when the user comes back they have a signed "JWT" token you can keep in a cookie.
That JWT token is attached to all API calls made the JSON backend as an Authorization Bearer token HTTP header. The token itself contains the users email address and is cryptographically signed by the Keycloak server.
The backend gets the JWT token in the HTTP header, extracts the email address and verifies the token is cryptographically signed by the keycloak server.
It's performing a certificate check on the keycloak server and can cache it's certificate. So it doesn't need to have roundtrips like OAuth, or any upstream calls to make.
This gives us simple, low-chance-of-failure, high speed authorisation in our JSON backend API and means we aren't putting secrets in the iOS client, or rolling too much of our own code.
I'm developing a mobile app, the server side is REST using Spring 3 MVC.
I was trying to integrate Spring Security with it to secure resources. I've read through a lot of material to get information on how to do it. I understand the architecture, however, when it comes to implementation I am still confused.
I referred a SO question; I have the same requirements. I understand the code, however, I am confused about when the first authenticate request comes in; at that time a token will not be present as the part of the header, so the same filter won't work.
So I was wondering how should I implement it. I was thinking of implementing it as follows:
A separate filter that authenticates user using username password from the request
After authentication the filter sets the authentication info in the context
And another filter that works with tokens for authentication for all API URLs
Is this the correct way to implement it?
No need to add another filter. Whatever the authentication result, the system will try to call handler for corresponding mapping, as you have chain.doFilter() outside if(validate_token).
You must tell Spring security that your request /login MUST NOT BE AUTHENTICATED. You can configure it in xml/java config.
I need to develop a REST Web Service using ZEND Framework. I am new to this area. I would like to know how can I authenticate user's requests to my web service. Assume I am giving a token to all the people who use my web service. I can ask them to pass the token on every request. But Please suggest me if there and standard / better way to implement authentication for REST web service.
Thank you.
Prasad
I usually include the token in the http header with each request then on the server parse the header and validate the token.
X-Authorization-Token: <some hash value>
It's also completely acceptable to do as you are suggesting and require the user to send the token as part of the GET/POST/PUT/DELETE request as you would with a standard page. I have seen others put the value in a COOKIE as well.