I have a WebForms app using external login (Microsoft and Google) and ASP.Net Identity 2.
I want the external login to persist when user comes back to the web site. Currently when user comes back they have to login again using the external provider.
I understand one way to do this is create persistent Application Cookie after locating the user like answered in this SO question.
But this is not acceptable since the requirement is that the user should be signed out if they sign out from the external provider.
If I create persistent "Application Cookie", Is there a way I can validate if user is still logged in externally.
OR
Are there any other ways of achieving this?
Related
We have a TYPO3 CMS to manage user base and as a portal for various user-specific information. We also have a separate ASP.net C# application used for charting visualization with many of the same users with a separate admin backend . Looking to get rid of login portion ASP.net application and use TYPO3 session authentication. Idea is for the user to be able to click a link within their Typo3 frontend and get directed to the ASP.net application which can then authenticate with the Typo3 session and act in accordance. Just wondering if my best bet is to write something in the ASP.net app to get the TYPO3 session cookie (is that possible?) or if I have to do something clunky like oauth2/other service
I would write a TYPO3 authentication service that contacts your ASP.NET app via one of known protocols (REST?) or even custom protocol and checks authentication. If it is successful, the normal TYPO3 authentication process goes on.
It is not enough to simply set a cookie during the authentication. There are other things that has to be done for the user to be "set up" as logged in.
I have been tasked with integrating single-sign-on for an existing application, so I've been working on a couple of demos. The first one was the standard demo for Spring Security and I got that working. Now I'm trying to do a proof-of-concept demo where I created a toy version of the application in question with only two screens: one for login, and one to display some information about the user that logged in. I want to integrate SSO with this application so that the user has two ways to be authenticated: either by entering credentials directly in the login screen or by a SSO SAML request...
So I copied over SAML libraries and configurations from the standard SSO demo into my proof-of-concept application, and I seem to have SSO working, albeit a bit too well, in that I'm no longer able to get to my login screen, i.e., I still want that to be the default behaviour for someone entering the base URL for the application. How do I have to configure my application to achieve this?
The way I solved the problem was by changing the Spring Security configuration so that instead of using the generic /** to require SSO authentication for most pages of the application, it nows only requires such authentication for a single HTML page, sso.htm. This "page" is really translated by the application as a request to a controller that handles the application-specific processing for an SSO request. The initial page for the application, redirect.jsp, now contains some logic to pick which page a user should be redirected to, based on whether he or she got to that page directly (i.e., by typing in the default URL for the application) or via a SAML message from a trusted identity provider.
Note: For this to work, the initial page cannot be designated in the Spring Security configuration as either a secured or unsecured page. If it were secured, then this page could only be accessed after an SSO authentication, so a user would be thwarted from doing a non-SSO login. If unsecured, then the security context would not be accessible from that page, so the page logic would be unable to determine if the user in question has SAML credentials and an SSO authentication request for the application could never be fulfilled.
Once the user has been authenticated, either by credentials entered in the login screen or by an SSO request, from that point on, the application's continuing authentication of that user to view its pages is the same, i.e., no further SSO authentication is done. But when the user logs off from the application (or is logged off due to a session timeout), a check is made then to see if SSO authentication was done for this user. If so, then in addition to being logged out from the application, a local SSO logout is also done for the user, i.e., the SSO authentication session for the application is terminated, but the user remains logged in with his or her identity provider. So such a user could log back into the application in question, either directly via the application's login screen or by having the identity provider issue a new SAML message.
Hope this helps someone else...
I'm developing a web application that requires the user to log in using forms authentication. inside the webpage you need to download a desktop application that requires to login to the same system too. Is there a way to transfer the current logged credentials from the web application to the windows desktop application without need to login again?. Both applications shares a Login object from an vb.net interface.
I tried to save the IP address in the Database but that don't work for me because the website needs to be accessed inside and/or outside of the company and the user cannot login twice in different machines.
I tried to google for solutions but without luck.
Do you have any suggestions regarding this?
This may not be exactly the scenario you're envisioning, but this article shows how to use Forms authentication from a Winforms client using WCF Authentication Services. This should get you going in the right direction. Per the article, you can use these services in any .NET application.
http://msdn.microsoft.com/en-us/library/bb386582.aspx
This article shows how to do it with a Silverlight app, just so you have another example. http://blogs.msdn.com/b/brada/archive/2008/05/03/accessing-the-asp-net-authentication-profile-and-role-service-in-silverlight.aspx
And just one more for fun. http://aspalliance.com/1595_Client_Application_Services__Part_1.all#Page1
There isn't really any way to share this without encrypting a file containing the user's credentials and storing it on the hard drive along with the file, but then you run the risk of someone decrypting the information and getting access to the user's password.
I think that an alternate approach that could work is to generate an authentication token (could be as simple as a GUID) and store it in your database along with the user's id when the user requests the download. You would want this token to expire after a reasonable time limit (5 minutes, for example).
You could then include a file that contains this authentication token with the download. When your apps starts, you could check for the existence of the file. If it's there, you extract the token, delete the file, send the token prior to presenting the user login.
If the token valid, your server would send back the user's login and your app would proceed as though the user were logged in, otherwise you would just display the login screen.
currently I have a website with authentication using Microsoft.IdentityModel.Web.WSFederationAuthenticationModule. It redirects me to login page (single sign-on outside my website) and upon login, I am redirected to default page.
Now, when I was using CreateUserWizard asp.net control, it seems that upon creation of user, the control tried to use my machine name to login to db server (i.e. '\$') instead of using SSO login which has just been done.
Does anybody know how to customize the control to use federation login to connect to db server? In addition, how to set so that the control will use certain specified sql account to login to db server?
When you rely on federated identity, you typically won't "create users". Those would be handled by the identity provider. You might want to consider rethinking your app a little bit. For example: given that users will be provided for you (through the IdP), what does it make sense to do in your app? (e.g. associate users, manage authZ, etc). But likely not "create ones".
Here is my problem :
1) I have an ASP.NET website which is the main entry point in the application.
This website uses Forms authentication, which validates credentials (username/password) against a database.
2) Once logged on the website, the user is displayed a page containing several links which point to a Sharepoint 2007 application, where authentication is managed by an Active Directory.
3) Every user in the Active Directory is duplicated in the database managing the ASP.NET website authentication.
4) The ASP.NET website and the SP 2007 application are NOT on the same domain.
The problem we are facing is that the users first have to enter their credentials to access the ASP.NET website. Then, clicking on a link pointing on the SP 2007 application, they're prompted another .htaccess-like window in order to authenticate them against the Active Directory.
The question is :
Is it possible to kind-of pass the credentials the user first entered to access the ASP.NET website in the HTTP context so that when he clicks on a link pointing to SP 2007, he's not asked to enter his credentials again ?
I've already successfully validated credentials against an AD, but I'm stuck at where do I have to extend the ASP.NET authentication process so I can inject the SP-related domain credentials into the context.
Hope I was clear, feel free to ask for more information if needed.
And just to be clear, bypassing the first step (ASP.NET website authentication) is mandatory :-)
Thanks everyone,
Mick
Does sharepoint have ntlm or forms based authentication? (I'm guessing ntlm because of the login poup)
I have built something like that with sharepoint forms auth where:
1.User logs into ASP.NET application
2.Auth cookie created
3.Auth token stored in database
4.User goes to sharepoint
5.Custom HttpModule checks cookie and token
6.Logs user into sharepoint using HttpApplication.AuthenticateRequest and FormsAuthenticationTicket
I suppose you could do something similar with ntlm auth but it might not be possible as the browser is doing the authentication. A whole bunch of different headers get sent. (eg WWW-Authenticate Authorization). It must be noted that developing a custom HttpModule is not a novice task.
You said:
3) Every user in the Active Directory is duplicated in the database managing the ASP.NET website authentication.
I hope the passwords are not clear text in that database
And said:
And just to be clear, bypassing the first step (ASP.NET website authentication) is mandatory :-)
Do you mean "is not mandatory"?