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
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?
Looking for direction.
I've got a single web application that I want to SSO into from multiple applications that all handle their own authentication. The web application wants to use SAML for SSO'ing. The web application requires IdP metadata (we've got one web service that is its own IdP, don't know what the other applications are using). The web application can also accept SAML Assertions with provisions to determine user access when it creates the new users after they SSO in.
I'm looking to get a one stop shop for the web application to hit to determine authentication and authorization.
I've got another web application (.NET Core) that runs Identity Server 4 to handle authentication for one of the many applications that wants to SSO into the web application. Can I use that? I would need to integrate SAML into it. How do I do that? Also, how can I easily integrate all the other applications to use this one web application to SSO into the SAML web application. Is this what Federating is?
Trying to do this with minimal work to all the other applications because that kind of integration work across multiple teams would be kind of a nightmare.
Any suggestions?
Thanks!
If you're already using Identity Server 4, you're probably best to stick with it and add SAML SSO support to it.
SAML SSO support isn't included natively in Identity Server 4 but there are two commercial offerings that add this support.
The following link has some good articles describing how to support SAML SSO in Identity Server 4.
https://medium.com/the-new-control-plane/tagged/identityserver4
Say I'm a small application (www.example.com) and I'm integrating with a much larger enterprise (www.acme.com).
In this scenario I am the service provider and they are the Identity provider.Their request is that I integrate into their auth ecosystem using SSO (specifically SAML 2.0).
For the standard IdP-initiated flow, users will sign in on their end and they will POST an XML assertion to my application, which will then verify the user and sign them in to my application (i.e. set a browser session).
The enterprise uses PingFederate as their identity server, and they are curious what implementation my application uses. At this time I have none.
If my application is a single monolith (e.g. a small Ruby on Rails app), do I even need a federated server? Ultimately they are just looking for a place to POST SAML data to, so I can set up an endpoint and go from there right?
What are some general benefits of a federated server? Why wouldn't every service provider application (small and large) just set up an endpoint to ingest SAML data and call it a day?
Thanks!
You don't necessarily need a Federation server. However, if you decide in the future to divide/expand your application into micro-services or integrate your service with other 3rd Parties, a server will allow you to scale without disrupting your current customers (great CX) and not have to manage separate security endpoints.
I think we should move this to software engineering
How do users authenticate with your service? Having a federated identity guarantees that the whole user management process it's someone else's problem. They're looking for a way to integrate your service into their authentication system, so you need to set up an endpoint not only to consume but to be able to send SAML request to their identity server as well.
I use my Google Account credentials to access almost all my social networking sites (including Stack Exchange), that means among other things that all sites know me as the same entity plus I just have to remember the one password.
Don't know about SAML but almost everybody is using OpenId or OAuth.
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.