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.
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?
Please help. I'm aware there are several posts / docs about SSO implementations but I still can't seem to find one that addresses my use case - probably because I'm still new to SSO implementation.
Scenario:
I have an existing Symfony 4 application with existing users. I want so that when users log into the app, they are automatically signed into Outlook Office 365 (web). Exactly the same implementations on https://mysso.centennialcollege.ca/. Please NOTE I do not want office 365 to authorize my app using the code flow approach, rather I want office 365 to recognize users signed into my app as valid identities.
Has anyone implemented this or has ideas please?
Your question is a bit unclear. You're likely going to need to change the existing application in some manner in order to achieve true single sign-on. You'll need to ensure that authentication against the Symphony app leads to the presence of a session that can be used to trigger subsequent sessions in a SSO framework supported by O365.
In your case, I'd take a look at SAML and, more specifically, SimpleSAMLphp.
Are you affiliated with the organization you linked to in some way? Because just by looking at the login page that looks like they've already got some sort of SAML Identity Provider solution... you can just integrate your Symphony app with that IdP in that case, and correlate the principal returned to your SP application from the SAML assertion on successful authentication against the user data in your existing DB. You wouldn't have to use SSP in that case... any kind of SAML middleware would work.
I have multiple applications (made with different tech such as .NET, JSP, PHP, ... ). Each one of them have its proper login page which contacts the LDAP to verify the username and password (there is one LDAP for all the applications).
What I want is to do a SSO for these apps: One login page is to "rule them all".
The user enters his credentials once.
He chooses an app from list.
The app will load without accessing the original login page.
My additional questions are:
Is there anyway to implement a SSO solution without modifying the apps's source code?
Is there a trick to pass the username and password to the original login page and submit automatically?
You need an IdP, something like Shibboleth IdP or ADFS, which will handle the users from an Authentication Source and do that hard stuff like the login page, etc. Usually there's user management headaches here, i.e. how will users change their passwords, etc. That's where a commercial solution like Okta, Ping, or OneLogin might work better for you.
You need a SAML Service Provider for each of your apps (what SAML stack you choose largely depends upon tech used in site), or you can use something like Shibboleth SP which simply protects paths on the webserver. If the apps are all on the same one or two web servers, go with Shib, as it'll make the integration with ADFS simpler.
If you want to avoid modifying source code, something like Shibboleth SP is probably for you... it protects paths, and loads user attributes into server variables you can pull from (i.e. username, first name, last name, etc.) to render on your app.
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
I have a question regarding ADFS and forms authentication. I currently maintain a database of users and have built a somewhat complex claims-based system around it. All of my clients use forms authentication to access my website (ASP.NET). Recently one of my clients expressed a desire to switch to a single sign on model. I would like to use ADFS to accomplish this. My question is how do I go about using both forms authentication and ADFS at the same time. I need all of my other clients to still be able to access the site using forms authentication. I know this cannot be a rare problem, but I can't seem to find any good answers to the question. Thanks very much.
using ADFS V2.0 allows both types of authentication, windows and forms and both relies on the active directory that means you must save and keep all the users data in the active directory.
pleases see http://www.richardawilson.com/2010/10/adfs-20-login-page.html
if you need the ADFS reads the users and credentials from another source than the Active directory,
in that case you must implement a custom claim provider and configure the ADFS.
Not sure I totally understand the question but ADFS can use FBA - AD FS 2.0: How to Change the Local Authentication Type.
Is your "complex claims-based system" a STS? If it is, just federate with ADFS.
If it isn't, have a look at Thinktecture IdentityServer.