My web application uses SSO authentication through Azure AD. From within my application, the user can access a network folder by providing required credentials. I would like to use the same SSO authentication that was done at login instead of manually entering the credentials to access the network folder. Is there a way to achieve this?
You cannot use the same token because Azure AD will Authorize only for initial login.
If you want to use the SSO solution for your network folder access which is accessed inside your web application, you need to create a new instance for your network folder access.
Ultimately you need to create two instances in Azure AD for your application to get the token to access both application sign in and network folder access with single set of credential.
You can create a new application with different name.
Now you no need to enter the credential twice in your application (SSO happen).
Related
Background
I have a web application "APP1" (front-end: Vue.js & Back end:Azure function) deployed in azure app service. I have implemented client directed sign in (easy auth using this), after that I can authenticate user using provider's sign in page [both AAD & google].
Target
I have another web application "APP2" deployed in on-primes server. I want to redirect to APP1 from "APP2" and automatically sign in without provider's sign in page. I will read credentials from environment variable.
Tried solutions
I have found a similar issue here, however I am unable to use the solution because the DB between AAP1 and AAP2 can't be shared
I have also checked the google identity providers documentation, however I am unable to find how to programmatically sign in without provider's sign in page
Question
Is it possible to programmatically sign in to google identity to get token without provider's sign in page
The whole point of google identity is to prove the identity of the person behind the machine.
OpenID Connect is an open standard that companies use to authenticate (signin) users. IdPs use this so that users can sign in to the IdP, and then access other websites and apps without having to log in or share their sign-in information. (id_token)
OAuth 2.0. This standard provides secure delegated access. This means an application created by a developer, can take actions or access resources from a server on behalf of the user, without them having to share their credentials (login and password). It does this by allowing the identity provider (IdP) to issue tokens to third-party applications with the user’s approval. (access_token, refresh_token)
I implemented OpenIddict with ASP.NET Identity as a separate auth server and I use the client credentials and password flows. I also have a web api project as the resource server.
The resource server is deployed in IIS and needs to authenticate domain users as well as end users. All controllers have the [Authorize] attribute and the actions have a custom authentication filter inheriting from ActionFilterAttribute with which I check for permissions against the db. The resource server has integrated windows authentication.
Currently at this stage of the development I cannot use ADFS or AAD.
Domain users access the resource server using a Winforms app in which they pass their network credentials. End users have websites and native apps and will/should use password flow to get an access token.
So, my question is:
Should I have an endpoint with [Authorize] in the auth server with which the domain users can authenticate with? In this case I would also need to use integrated windows authentication (which I'd rather like to avoid).
And once the domain user is authenticated, should I use the client credentials flow to acquire an access token? Domain users do not need to be saved in ASP.NET Identity. End users will use password flow.
Is this the correct way to handle both Windows Authenication and OpenId?
The Azure sample active-directory-dotnet-native-desktop shows how to use ADAL to sign in for accessing a Web API from a WPF app. In the call to authContext.AcquireToken it's passing the Resource URL of the web service as a parameter. What if I just want to prompt the user to sign in to the desktop client itself and there's no Web API? Isn't there any sample for that?
Can you define what do you mean in practice with "sign in to the desktop client itself"?. A native app will prompt you only when you need to access remote resources, because they are the only ones that the user cannot access directly. If a resource is already on your local PC, and you have access to the windows session, what are you going to protect with the login? In other words, what is the resource or operation that a user cannot perform unless they go through a login? Having access to the windows session means that the user can do pretty much whatever he/she wants. Doing a login without accessing a remote resource would largely amount to theater.
We are developing a self registration app.
Our app allows users to register for web apps and is deployed on a weblogic 10.3.5 app server. The weblogic is connected to a local ldap system.
Once the user registeres with our app we call corporate servces to generate a user id. password activation, authentication is all handled by the corporate servcies. which also has a corporate ldap that contains all users in the company.
The approach works fine for 'new users' ie users that are not present in the corporate ldap or the local ldap: users enter their details and are issued a user id which we then copy into the local ldap once the user activates their account.
The use case we're grappling with at the moment is how to handle 'existing' users that wish to register. These are users that are currently in the corporate ldap and wish to 'register' with our applications. They get rejected during the normal registration process as they already exist in the coroporate ldap.
What i'd like to do is force them to login (simply so they don't register on behalf of somone else) and once they're logged in simply copy their data into the local ldap.
The problem is even if they are successfully authenticated by the corporate service, they don't (yet exist) as far as the weblogic server is concerned. is there a way to obtain the user id that comes with the authentication token ?
The authentication method is SAML 1.1
The application is a standard Java EE servlet based webapp using the struts2 framework.
Any ideas would be much appreciated.
Within WebLogic, you can define multiple authentication providers and set them up in the order you would like the system to use. Since you are copying data over, you would have to programmatically check for the existence of the account before attempting to create it on the LDAP server.
It would be a lot simpler if you use the external LDAP server directly instead of copying the data to the internal LDAP server, letting you attempt logging the user in and creating the account only while catching the appropriate exception.
I am using a WCF call to update my database with any changes from ActiveDirectory.
I call this WCF functin via client browser and the function trys to get details from AD within the servive itself. However the issue is AD needs UserName and Password to get any records.
Please advise how can I overcome this problem so that Windows looged in credentials are automactically accepted and AD is read.
I am using wsHttPBinding,Security: message and clientCredentials="Windows".
Thanks
Vikram
The call to Active Directory is going from the service.
The default settings for the service is impersonate=false and the identity of the application pool is NETWORK SERVICE.
Therefore, the call to AD is going in the security context of Network Service, which does not have the correct access, and cannot be given them, since it is a machine local account.
There are 3 ways to fix this.
Set Authenticate=true in the web.config to allow access to AD to be done in the security context of the calling user.
Change the identity of the application pool to that of a domain user that is allowed to access AD. Be sure to add this user to the local IIS_WPG group.
Store the username and password of a user that is allowed to access AD, in the web.config file, and use these credentials to access AD.