I am developping a Restful web application with Symfony2 and I will use FosOAuthServerBundle and OAuth2,I started to read some tutorials, but one thing I didn't understand,in my application I have already an authentication system in which the admin put his login and password,but the implementation of this bundle in my application adds a second authentification system to my app,for this reason as I have understood I should add a button in my login page to use this bundle and having the access token to protect my rest web service
My question is,what are the advantages of this second authentification system,espitially my application is for one user "the administrator"??
My second question is,is it possible to combine this functionality with my login system that I have created from the beginning
thanks a lot for help
The advantage of using oAuth2 is that is standardized, so you can use any client in any language out there to get an access token.
If you have a single admin user, probably you don't need it but is up to you decide that.
I'm quite sure you can integrate your auth system to the oAuth bundle by following the symfony2 security documentation and implementing an user provider
http://symfony.com/doc/current/cookbook/security/custom_provider.html
Related
I'm building a platform on .Net5 that will consist of at least 3 MVC web applications: User, Admin, Product. Authentication is performed on the User application where we can take a Username/Password to log the user in. The User Application also has the Forgot Password/Reset Password, etc functionality on it. Authorization is claims based. Based on this document I believe I would fall into Figure 9-2 Authentication by identity microservice, where my other microservices are web applications rather than APIs.
The issue I'm running into is trying to figure out the proper way to implement this.
Do I use JWT or Cookies for this? The article above does have a link for cookie sharing but wouldn't JWT be appropriate?
If I did use JWT, how do I pass it back to the server if I used something like #Html.ActionLink? Or is it expected that I would be using a front end framework like React and thus making any calls back to the server manually?
Again, if I'm using JWT, how would I pass it from the User application to the other applications?
We have big JSF monolithic application. We want to change the architecture of this application. Currently, my goal - change one module in our application. I need to move the logic from one module to another application which will be implemented on another stack of technologies (it will be rest-service with some js-framework on frontend).
The application should work in the same way. We should have the link to the page as it was earlier but this page should be rendered by another service. We should have the same session between these 2 applications. The user should be able to go throw the pages without an additional step of authentification.
We are planning to move also other modules, not only this one. I need a help. Do you have any thoughts how it should be implemented? any examples?
The ideal way to do this for me is using a SSO service like keycloak, as your Identity Provider. That involves porting your authentication logic to it and decouple it from your monolith. But once you rely on it as your IdP, you only share tokens between your applications and IdP. Keycloak has many adapters, for Java, Javascript, NodeJs clients.. and so on. That has the huge advantage that you can keep decoupling logic from your monolith and you don't even need new modules to be written in Java. You could even integrate it with services not written by you, it's enough for them to have Open Id Connect or SAML integrations.
KC supports both SAML and OIDC Auth protocols. With OIDC (the way to go with brand new applications), the adapter located in each of the apps checks wether the user has a valid web session or not. If not, it gets redirected to KC login page. The result of a valid login is a code which you can use to obtain an access token (a valid token to obtain resources from your app). Apart from that, the adapter ties that access token to a browser web session, which is stored in KC too. So if you try to access the other web page, the adapter checks for your web session, which finds to be valid.
You can use it to access your apps from a mobile device too, taking care of the access token management/renewal in the mobile app yourself.
See also:
The OpenId Connect protocol
First, let me describe the application: we are working on a web-based software which is some kind of custom help desk application. It requires the user to login (we use FOSUserBundle). After login the user is redirected to the dashboard. From the dashboard there is no more page reload, the frontend is build on Angularjs and the user can get anywhere within the application without page reload. You could speak of a single page application.
So the data that is presented to the user, is fetched from a rest api (we use FOSRestBundle). This works quite well at this point.
There is some kind of dilemma. Only our staff will access this application (for now). So a staff member needs to login to access the helpdesk. The data that is pushed to the frontend via angularjs is called via api, so the user that has just logged in needs to authenticate again on every request because of rest.
Problem: Since the backend runs on symfony2 let us just try to get the user object of the currently logged in user when an api call is made:
$this->get('security.context')->getToken()->getUser()
returns anon. that stands for anonymous, or
$this->getUser();
returns just null.
So the authenticated context seems to be gone when using the rest api. However when I call an action directly without rest, I can get user information.
So what we need is to secure our rest api and get user information on every api call. We don't want third party people to access our application, just staff. I am not familar with OAuth, but the user will be redirected to a third party page to Allow/Deny access to his data? This would not be an option for us.
Based on that information, do you have any suggestions or ideas how to secure the api and transport the user data so that getUser does not return null or anon. but the actuall logged in user?
there's another way to resolve your problem.
It's by using Certificates.
you can generate certificates then use Http tunneling (https obviousley), the server will ask for a certificate (you've to configure Apache for that but it's not a big challenge).
with this in place, you've to add a CertificateManageron the server side to ensure that the certificate is valid and to know who's calling the service (to be able to authenticate the user at each request), the CertificateManager(or what ever you'll call it) will probably have to be configured within you filters chaine (as known in the java world), et voilà
Hop that help you,
Abderrazak
REST is stateless so you will have to send some kind of authentication/authorization in each request. You can use HTTP BASIC AUTH or something like OAuth.
Have a look at https://github.com/FriendsOfSymfony/FOSOAuthServerBundle
I'm kind of building our application in exactly the same architecture (RESTful API with Symfony2 back-end and AngularJS frontend.
Another way is to duplicate the api routes, so that you have the api routes protected by OAUTH and the api routes protected by the session, both of them pointing to the same controllers. The method was explained here: https://stackoverflow.com/a/22964736/435026
Im trying to build an OAuth 2 provider and for the web server flow its very strait forward but i cant figure out the best way to implement an installed application flow
most examples ive seen follow essentially the web server flow within an embedded browser in the mobile application, this is also generally how facebook and google demonstrate 3rd party apps to use their APIs
but do facebook and googles own mobile applications actually use that flow or is there some better way to implement mobile authentication
my main problem stems mostly from the client id and client secret, if its embedded in every installed version of a mobile app it becomes essentially useless as it can be easily sniffed, and there's no clear oauth 2 examples of having a per application basis for the client secret
so whats the best way of securing my own mobile app using oauth 2
As you probably want to have user-based authorization and do not want to deal with a username/password on client side, this leaves you the choice to using the Implicit Grant flow or the Authorization Code Grant flow (what you call web server flow).
Now check out the OAuth 2 specification's Installed Applications section. There they state:
When choosing between the implicit grant type and the authorization code grant type, the following should be considered:
Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential.
When using the implicit grant type flow, a refresh token is not returned, which requires repeating the authorization process once the access token expires.
Whether to use an embedded or an external user-agent is also widely covered by the specification.
For implementing this securely (at least as far as this is technically possible on an open platform), search the specification for the word native and read the sections containing that word multiple times, especially the Client Authentication and Client Impersonation sections.
Curious what recommendations anyone has.
I have an existing asp.net forms application that does a Forms Authentication and has identity impersonate turned on.
The application has a link to a questionnaire that I would like to develop separately in an asp.net MVC application, but I don't want the users to click on the link and be prompted for a username and password, I would like them to be able seamless start filling out the questionnaire.
Is there a way to somehow transfer authentication from one .net app to another? I would like to be able to pass stuff like UserRole.
What's the best way to do this?
If you use the same MachineKey in both applications and the MVC application is on the same server, I think that it will reuse the auth cookie and simply consider them logged in. See this MSDN article on configuring the MachineKey, especially the section on sharing authentication tickets across applications. Note this assumes that both applications are on the same server. If they are on different servers then you'll need to investigate some other mechanisms -- say generating a single-use ticket for the URL that can be used by the remote system via a web call back to the originating server who the user is. It might not need to be a full-up implementation of a central authentication system, but along those lines. Just be sure that you're using SSL to encrypt the relevant bits to help avoid man-in-the-middle attacks.
Using Windows Identity Foundation (WIF) you can achieve Single Sign-On.
In WIF, a service called a Security Token Service (STS), issues a token with claims, which can be anything you want to declare about the authenticated user, for instance his roles. In your apps you can use the Page.User, Controller.Page or Thread.Current.Principal properties to check the User claims (though if you'll only be using role claims you can use the IsInRole method for simplicity).
You can easily create a STS using the tools for VS included in WIF's SDK. The Forms authentication will be done in the STS instead of in the Web Forms site and both sites should have a trust relationship with the STS.