TYPO3 external authentication - asp.net

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.

Related

Custom authentication on IdentityServer4

I'm digging into building an identity server using IdentityServer4, and I have some business logic that i want to implement on password change, and on password persist.
On the asp.net core page built into the IdentityServer that I've made using the startups, I can achieve it on the controllers provided, ok.
But, I wanted to be able to change the password check for a token grant to a windows client or mobile client for example,these clients won't do the login from the asp.net page.
How can I acheive this?

Persisting External Login using Asp.Net Identity

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?

Sharing sessions between DNN and Custom app

I have setup a DNN website with domain
www.abc.com
Now I require to build a custom application in asp.net and host it in
domain
www.custom.abc.com
The users who have logged into DNN (www.abc.com) should not be prompted to login again in www.custom.abc.com.
Basically, I want to share the Sessions used by DNN to my custom application. Is this possible ? Need some ideas for my starting point.
If you wish to share authentication cookie, you can do so by setting same keys in the web config.
Please check Forms Authentication Across Applications
Sharing sessions is a bit more difficult if those are two different applications, and it would require some custom coding.
Maybe you can add some logic in global.asax Application_BeginRequest event to check if user authentication cookie exists (User.Identity.IsAuthenticated), and if user is authenticated, but session is NULL, just recreate needed session.

Is it possible to validate an ASP.NET Forms Authentication ticket in ISA/UAG (or similar) and do redirects based on the result?

We have an ASP.NET MVC application that uses Forms Authentication to create and validate the authentication ticket (cookie). The log on flow is very special, not just username/password, but it ends with a call to FormsAuthentication.SetAuthCookie(userId, false) to create the cookie. So a standard cookie is created, it is just how it is created that is special.
We will also have to integrate with a couple of other web sites that are not neccessarily .NET based or not possible to customize via some kind of Single Sign-On that do not require any modification on the other sites. All sites are behind the same UAG/ISA Server.
Is it possible to setup some kind of filter in UAG/ISA Server that can validate the Forms Authentication cookie created by the ASP.NET MVC application? If it is not OK it should redirect to the log on page in that application? If it is OK it should just let the request through. For example, would it be possible to use a ISAPI filter with UAG that does this? We can use the same machineKeys on the UAG server and the ASP.NET app server (I guess that is required to start with)
I don't know much about UAG and I'm also interested in alternatives to UAG. In fact, what we really need is just something that works as a perimeter protection for all those sites and that can utilize the already existing log in flow/cookie.

How to Anonymously Authenticate between a VB.Net Desktop App and ASP.Net Web App

I'm looking for a way to pass some sort of credentials or Authorization token from a VB.Net Client to an ASP.Net web application that allows the Client to auto-login to our Forms-Authenticated website. If a user is logged into a local application, I want them to be able to view some web pages without having to login to the website as well. The credentials are not the same between the apps, but I would just like to pass some sort of encrypted token or key to the web page so I know they are coming from the desktop application. Is this possible without requiring a username and password login?
I also need to make sure this URL that is used cannot be simply copied and used from another location, so I'll need to include some sort of information in the encrypted value to know where it's coming from.
I know how to login the user with Forms Authentication and all that, just need to figure out the best way to secure this. Thanks!
OAuth is commonly used to allow desktop applications to access a user's private data on a web site. Since you're using .NET, I suggest you check out DotNetOpenAuth which includes sample OAuth web sites and client applications. It allows for this secure token to be passed that can tell your web site that the desktop app is the one making the requests and (usually) whose data is being accessed.
The best part about the OAuth solution is your desktop app never has to ask for the user's credentials. No credentials are in the URL. And if the desktop application is ever compromised (perhaps by the computer being stolen), the web site can kill the secure token the desktop app was using to cut off access without requiring the user to change their password.
You might want to look into issuing client-side certificates for these applications. Basically, you generate a certificate that you install with the client application and then on the server side, you check the ClientCertificate property of the HttpRequest instance exposed by the Request property on the current context.
Note that what you are doing is really a very bad idea, in that applications should never be assigned identity, only users. To that end, you should be authenticating each and every user that is using your app, not considering the application to be the identity. It's commonly considered a bad practice to do such a thing.
You can share credentials between the applications using ASP.NET Client Application Services.
Here are some resources:
Client Application Services
Client Application Services with Visual Studio 2008
Is your desktop app running on machines that are in the same domain as your web server (i.e. all in the same company)? If so, Integrated Windows Authentication is your easiest solution.
I think its best idea to use a web browser control inside the desktop application .
Then use the WebBrowser1.Document most probably
WebBrowser1.Document.Cookie
get if the user is singed in.
I also need to make sure this URL that
is used cannot be simply copied and
used from another location, so I'll
need to include some sort of
information in the encrypted value to
know where it's coming from.
If you store the encrypted value in a cookie or as a field in a form (POST request), then the credential is no longer in the URL and so it can't be easily copied (note that I said "easily").

Resources