I have created user pool and configured with asp.net core API that communicates with AWS for Login/signup etc.
I have three stand alone applications build in asp.net I want to integrate these application with AWS through that API.
API is working fine that is able to sign in, signup, forgot password, reset password password etc. but how can I maintain the session(identity) in my all three applications and i also want to implement Single Sign On (SSO).
I am using AWS SDK along with libraries:
Amazon.AspNetCore.Identity.Cognito;
Amazon.Extensions.CognitoAuthentication;
are they web apps? if yes, your browser will maintain the session with Amazon Cognito.
Related
We have a hybrid Active Directory scenario - an on premises Active Directory server synced with an Azure AD tenant.
We are in the process of migrating our on premise Exchange email accounts to 365.
We have a SPA (JavaScript) that displays calendar events retrieved from a dotnet core web API.
The web API only allows access to users in a specific AD group.
The SPA uses the Fetch API to call the web API with credentials.
The web API currently uses EWS to connect to our on premise Exchange server to read calendar events, using its app pool identity.
The above systems have been developed in-house and run on our internal servers.
We want to update the Web API to read calendar events using the MS Graph API, on behalf of the user. We would like to use the simplest available solution.
We have tried to use the AcquireTokenByIntegratedWindowsAuth method but receive the following error: 'Integrated Windows Auth is not supported for managed users'. My limited understanding of why this doesn't work is because we do not have an ADFS on premise.
One of the Microsoft samples shows a SPA acquiring an access token and passing the token in the header as part of the web API call. This would require us to update the SPA and web API code. We're willing to do that if it's the only solution, but I am hoping someone might offer an alternative where we only need to update the web API.
I need to provide an SSO between two independent applications via the Azure AD SSO.
My app (A) use Firebase as the backend and currently isn't registered in Azure AD.
The second App (B) is registered in Azure AD via App Registration and I think has password-based login now (but it doesn't really matter). Can't say what technology it uses for the backend.
I've read a lot of Azure documentation but can't understand how exactly should I connect them with SSO.
I see that I can connect applications from the Enterprise Applications list. Is this the only way to do it? In this case, I need to publish my app to the Enterprise Applications gallery but it feels like an overcomplicated solution.
SSO feature and experience depends on the type of auth-protocol being used. It also varies based on that. Lets say, your app uses OpenIDConnect then the SSO experience would be something like what mentioned here: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-oidc-single-sign-on
If it uses SAML as the auth-protocol it looks something similar to: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-saml-single-sign-on
and if its using Password-based SSO then: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-password-single-sign-on-non-gallery-applications
Specifically for Password-Based SSO, it provides SSO by storing the credentials in the browser extension. With password-based sign-on, users sign on to the application with a username and password the first time they access it. After the first sign-on, Azure AD supplies the username and password to the application.
Password-based single sign-on uses the existing authentication process provided by the application. When you enable password single sign-on for an application, Azure AD collects and securely stores user names and passwords for the application.
Choose password-based single sign-on when:
An application doesn't support SAML single sign-on protocol.
An application authenticates with a username and password instead of access tokens and headers.
In your case, both you apps (MyApp-A and MyApp-B) needs to be registered in AAD and they should support neither SAML or OIDC.
Is it possible to mix authentication types in a C# ASP.NET MVC web application hosted in Azure?
I have an ASP.NET MVC application written in C# that uses ASP.NET Identity as its authentication system.
A customer has asked if they can sign into the application using their Azure Active Directory (SSO using openconnect id).
I can recreate the application using openconnectid and assign their tenant as the AAD directory but users from my company can not log into the application because we do not exist in the customers Azure Active Directory.
We need to be able to log into the application because we perform data entry tasks for them using the web app.
Has anyone come across a similar issue?
Regards,
Graham
You may need to show login screen with 2 possible options. You redirect the user to their respective identity provider , they get authenticated and bring back the access_token/Id_token to access application resources.
Very much like different OpenID connect providers in the same application(FB, Google, Microsoft etc) and regardless of which provider user choose to get authenticated the token is same to access resources.
I have a ASP.Net WebAPI service that is used by my AngularJS front end and I am making use of Owin and bearer token.
Now there is a need that we need to install an agent on the few of the client machines (developed in .Net core mostly) that is able to connect to our application and make similar calls. I can create a separate controller for this need, but want to host it in the same website.
How can I create a secure connection between this agent and the ASP.Net server hosted on Azure?
Currently I am looking at generating a Token during the agent installation based on the client MAC address and giving it with each call, but I am checking if there are any better way to address this need.
Any help in this direction is welcome.
Regards
Kiran
It seems that you’d like to enable only valid “agents” that installed on the client machines to communicate with your server, if that is the case, Azure AD provides Native Application to Web API authentication scenario (a native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API that is secured by Azure AD), you could refer to it.
I've been assigned to find a way of implementing SSO in our products. We have several Winform applications and one asp.net 4.0 web app (not MVC).
All the products are built using .Net 4.0, the web app is ASP.NET 4.0.
Some of the Winforms are commmunicating with our API via web services (asmx) and some uses our API directly. The web app is using the same API as well. We offer a set of web services (asmx) that uses the same API to external clients.
Currently we have our own authentication implementation (user, password, roles) in our systems and we would like to replace that with SSO. Or can these two authentication regimes co-exist somehow? The Winforms are used in intranets and the web app is used both in intranets and we also hosts the web apps for clients (accesible from the Internet).
The users are created in our system, but at the same time we import users from Active Directory using our own tool. Active Directory is really the primary user source.
I have read about Windows Identity Foundation and I wonder if I can use that to implement SSO. But what I don't understand is how to use WIF in the winform applications when they use the API directly.
What I would like to achieve is to remove all user administration from our system and use Active Directory as the user source. I guess that means using ADFS 2.0 to create claims, etc.
I can use .Net Framework 4.5 in this implementation (I know that WIF is now a first class citizen in .Net Framework 4.5).
Do you have any advices how to do this? Is WIF the best alternative to achieve SSO across winforms applications and web apps?
There is a way to get the WIF authentication cookie from within the WinForms application.
To do it, you just host the WebBrowser control and point it to the login page of your web application. Assuming the web application is federated with the ADFS2, the web browser control will automatically follow the flow - it will redirect to ADFS and stop there to show the prompt for user credentials (ADFS2 in Forms Authentication mode) or just authenticate using NTLM/Kerberos (ADFS2 in Windows authentication mode). Then the web browser will redirect back to your application.
This is where you hook your code. You just add a handler to the web browser's navigation event and you check when it comes back to your application AFTER ADFS2.0 authenticates the user. You can then call the InternetGetCookie method in the WinForms app to get all the authentication cookies issued by your application and you can close the window which hosts the web browser.
At this point, you have all authentication cookies issued by WIF (the SessionAuthenticationModule) for your application. You can now call your application web services and inject cookies into http calls. The web server will correctly recognize users as authenticated which means that all you have to do is to add proper authorization to your web services (the PrincipalPermission on your web methods should do).
An alternative approach would be to expose WCF services from your web application and guard them with WS-Federation active authentication. The downside of this approach is (in my opinion) that if your identity provider (ADFS) is further federated with yet another identity provider which DOES NOT necessarily implement WS-Trust/WS-Federation then the active authentication will probably fail (because the other identity provider does not implement it) while the passive scenario will still work (a bunch of redirects will sooner ot later end with a page which requires user to provide the credentials but the flow of authentication protocols between consecutive identity providers does not matter).