I have developed a mobile application using asp.net mvc3,html5,jquerymobile. I am authenticating the user using the ADFS authentication. Using IPAD or IPhone once the user is authenticated he is able to perform a download functionality in order to download an application. Now once the download functionality is completed when the user again tries to navigate back to the application he is prompted with the login window once again.
I need to stop the user from again entering the login credentials once again. So I thought of caching the user credentials will be good idea.
Can anyone help me to know how can we cache the user credential details in this case in order to prevent the user from entering the login credentials once again.
Thanks & Regards,
Santosh Kumar Patro
You could use persistent cookies. When authenticating simply pass true as second argument to the FormsAuthentication.SetAuthCookie method. This will emit a cookie that will be stored on the client for the given timeout period that you specify in the <forms> of your web.config.
Related
I'm creating an application in Blazor WebAssembly with Microsoft.Authentication.WebAssembly.Msal for the authentication. I followed this link. I'm using the RemoteAuthenticatorView component to perform a login. But I want that the user has to confirm his password for a critical operation. Or maybe he has to re-login. How can I do that ?
Edit: Previously, I used Microsoft.Identity.Client in a desktop application. To do the confirmation, I used the AcquireTokenByUsernamePassword function. But it's not possible in a webapp.
If you using the Azure AD Signin user flow a textfield for password input isn't possible.
This because the form containing the field has to be Remote inside the Azure AD domain.
If you want, as you propose as alternative, a popup to confirm the identity of the user, the only possibility is to logout the user and redirect him to the login.
But in this case you (he) lost any session data and it's hard to use the returnUrl parameter to restore the same status, with i.e. a form with data.
I think should be better to send an email with a verification code, or, as Microsoft does on the Azure Portal, request a keyword to confirm the operation.
Generally speaking this keyword could be any of your choice, in the past I've used a secret word configured by the user himself inside his profile page.
When I call agent.logout(...) with the account that I logged into my application with, I get logged out of my application but I am also logged out of Outlook on the web that I have open in another tab.
How do I logout of only my application (registered in AAD 2.0 of course) but not logout of Outlook on the web? I provide the "account" that I logged in with that should be tied only to my specific application.
This is intended behavior, given both applications rely on the same AAD session. If you would like to only remove the session information for the MSAL instance on your website, you can manually clear local/session storage, instead of using the MSAL logout API (which will send the user to the AAD logout screen).
If you would like the ability to configure logout to only clear browser storage and not making a network request to the AAD logout page, you can open a feature request on the MSAL.js Github repository.
I think that makes sense. I guess I'm not familiar with how AAD sessions overlay/influence the oauth process. I'll open up a feature request. Thanks
We have a desktop application that is used to upload content to a web application, both use Okta for authentication. Before uploading, the desktop application authenticates the user via Okta using an embedded browser control. Later in the workflow we want to open the user's default browser so he/she can start using the web application directly. At the moment the user will need to login a second time when their default browser opens.
We planned to implement a mechanism to generate a one-time key (transferable session token) that can be passed as a URL parameter when the browser is opened. For our application's own token we can achieve this but we also need to transfer the Okta session (cookie) and we have not found a way to transfer this from the desktop browser control to the standalone browser.
What options are available to achieve this?
Edit: it is acceptable if a new session is created for the standalone browser as long as the user identity stays the same and the user does not have to provide login details a second time.
Unfortunately, Okta does not have a way to transfer one active session to another as you describe.
However, if you have enough control over the organization's environment, you could simulate this behavior. For Okta organizations that use IWA to authenticate users, you would get this sort of feature "automatically" (provided that the user's default browser supports Active Directory). Another way could be to configure your web application as a "SAML IdP" and have it "transfer a session" to Okta using a SAML Response and Okta's Inbound SAML functionality.
I have a site which is built in ASP.net and C#. Let's call it webapp. it uses a Form system to log on into it, and cannot be changed easliy.
I got a request to change the log in to some kind of windows authentication. I'll explain.
Our windows login uses active directory for users to log into their windows account. their login name is sXXXXXXX. X are numbers.
in my webapp, I want to take the users numbers from their active directory login, and check if those exist in the webapp database. if it exists, they will automatically log in. If it doesn't, they will be referred to the regular login page for the webapp system which is currently in use.
I tried changing my IIS to disable anonymous login and enabling windows authentication, therefore making the user browser to send it's current logged in user name to my webapp. I changed the web config as well from "Forms" to "Windows", which made my whole webapp obsolete as the whole forms system did not work.
My question is this - is there a different way for the browser only to send the username to my webapp? I thought maybe javascript, I just don't know how to implement that, if it's even possible. I know it's not very secure, but all this platform and system is built outside the internet, it's on a private network.
<script language="javascript">
var username = '<%HttpContext.Current.User.Identity.Name %>';
</script>
The only way you could get at the user's domain credentials via javascript would be by deploying some type of ActiveX component to expose that data to the browser. I wouldn't recommend that.
I would look at implementing a Login page for forms authentication that authenticates the user on the page load using HttpContext.Current.User.
The way forms works is that if an unauthenticated user attempts to access an access-controlled page and have not logged in (no cookie), they will be redirected to a login page that gives the facility to log in (this sets a cookie on the client-side). The user is then directed to the page they initially requested. You would simply be automating the login part.
If you have a mixture of pass-through and user who need to manually login you could check their client IP address to see if it matches one on your domain or not.
The solution I found for getting the username sent to the server was:
string winlogon = Request.ServerVariables["LOGON_USER"];
After enabled Windows Authentication Mode in IIS.
I am trying to understand concepts of windows authentication, forms authentication and their differences. I am confused. Can someone help me in clarifying this.
Thanks.
Windows Authentication provider is the default authentication provider for ASP.NET applications. When a user using this authentication logs in to an application, the credentials are matched with the Windows domain through IIS.
There are 4 types of Windows Authentication methods:
1) Anonymous Authentication - IIS allows any user
2) Basic Authentication - A windows username and password has to be sent across the network (in plain text format, hence not very secure).
3) Digest Authentication - Same as Basic Authentication, but the credentials are encrypted. Works only on IE 5 or above
4) Integrated Windows Authentication - Relies on Kerberos technology, with strong credential encryption
Forms Authentication - This authentication relies on code written by a developer, where credentials are matched against a database. Credentials are entered on web forms, and are matched with the database table that contains the user information.
Windows Authentication refers to authenticating against Windows user accounts on the box that the application is running on.
Forms authentication is a stand alone method of authenticating in .NET forms that you can hook up to some other system, such as a database.
It's pretty simple. Windows Authentication makes use of the Windows Login system.
http://en.wikipedia.org/wiki/Integrated_Windows_Authentication
And with Forms Authentication the user will need to provide a username and password manually.
http://www.asp.net/web-forms/tutorials/security/introduction/an-overview-of-forms-authentication-vb
The Forms Authentication also allows you to choose where you access the login data from. It could for example be stored in your own local database. While Windows Authentication is only going to use your Windows login data. This data usually comes from Active Directory, if your network is built using an enterprise/buisness/domain setup.
http://en.wikipedia.org/wiki/Active_Directory
Windows Authentication-- The user will be authenticated on the IIS server against the credentials he provided when logging into his system. If the authentication fails then a pop up form will be displayed in the Internet Explorer asking for his credentials i.e. username and password.
Forms Authentication-- A default Login Page will be available like Facebook login, where user will be authenticated instead of automatically getting the credentials from the system credentials i.e. the current user of the Windows system. If the user requests a secure page and has not logged in, then ASP.NET redirects him/her to the login page. Once the user is authenticated, he/she will be allowed to access the requested page. Here IIS does not come into effect for authentication, it completely depends on the web application.