We have a Vaadin / Spring Boot application which should be accessible via a browser and without login from intranet only.
We would like to implement SSO with the Windows login (Active Directory).
The goal is high security with least configuration as the application is sold to customers.
I came up with the following scenario:
receive the IP address of the client accessing the Vaadin-Application.
Look up in the Active directory / Domain controller, which is in RW mode and see which user is online with this IP address in this very moment.
check the rights of this user managed by the Active Directory Groups.
make application available with logged in user for the client requesting it.
IP spoofing is not possible (as the connection is bidirectional, also users have no access to network devices.)
this login process is only done once to initiate the session.
Am I correct with these thoughts? Can you see any security issues? Is it really necessary to use certificates?
What would you recommend if so? Kerberos, CAS, x509, SAML?
Related
First of all I just want to mention that I haver really bad knowledge of this topic. But my problem is that I have an grafana-instance running in openshift that is using oauth-proxy for authentication.
On my company we are using a Kerberos-solution to automaticly authenticate users accessing company domains. The problem is that we want to manage what groups that have access to the grafana-instance and if possible authenticate in the background without the users having to enter any usernames/passwords.
As I understand the current kerberos solution works like this:
User -> company.com -> SSO-server -> [fetch user from LDAP] -> If Authenticated, Redirect to company.com
Is it somehow possible to do something similar:
User navigates to grafana.company.com
grafana.company.com redirects to sso-server
Magic kerberos authentication occurs
Redirects back to grafana.company.com
someway authenticates the user directly from grafana or oauth-proxy
It is possible; any web-based SSO system that asks you for username/password can instead ask for a Kerberos ticket at the same point. (The latter is done using HTTP-level "Negotiate" authentication, also known as "SPNEGO".) Once the SSO system has established your identity, it'll happily issue the same OIDC or SAML tokens regardless of what kind of authentication was used.
For example, the Keycloak OIDC IdP has built-in support for HTTP Negotiate; search the docs for "SPNEGO". Shibboleth IdP (for SAML) has SPNEGO support as well.
Also, any SSO system that supports getting the 'REMOTE_USER' assertion from the web server (instead of using its own credential prompts) can be used with Kerberos, using e.g. Apache mod_auth_gssapi or Nginx spnego-http-auth modules.
My set-up has the following:
This is a multi-tenant system, so the set of User Claims includes tenant_id which uniquely identifies the tenant that the user belongs to.
An IdentityServer4-based web-service (this provides OAuth2/OpenID Connect services): https://identity.example.com.
A separate web-service (RESTful web-api): https://random-number-generator-service.example.com.
A headless program (Windows Service) that runs on on-premises computers at many locations: RandomNumberConsumer.exe. This program makes use of random-number-generator-service in the context of a tenant_id so a user needs to authenticate at some point somehow but otherwise the program does not care about the user's details, only the user's tenant's details.
I understand this means that both random-number-generator-service and RandomNumberConsumer.exe are "clients".
Within IdentityServer all client software must be registered (either statically as a hardcoded list of Client object instances or with some kind of dynamic registration using a database to store client details. Obviously random-number-generator-service will have a static registration, but how should RandomNumberConsumer.exe also be registered?
Some options:
Add a new web-application that users can login-to using a web-browser and register their RandomNumberConsumer.exe installation (which adds a new Client registration in identity.example.com's Client database, complete with a client secret) then the user manually copies and pastes the client secret into RandomNumberConsumer.exe's configuration file. The internal database maps each client registration with the tenant_id. This has the advantage of allowing individual client access revocation, but requires the user to perform manual configuration steps which are undesirable.
Have a single Client registration for RandomNumberConsumer.exe without any Client Secret, but the Client application needs a GUI component with which it can authenticate the user and it stores the user's associated access_token and refresh_token in its local configuration. This has the advantage of having a much simpler user-experience (as the user would open a RandomNumberConsumerConfiguration.exe program which then opens the web-browser to access the authentication page and gets the data using a redirect_uri with a temporary localhost or custom URI scheme value) but it means the RandomNumberConsumer.exe instance is associated with an individual human user when we only want it to be associated with the tenant instead.
Are there any other approaches that could be used instead?
Every instance of a client should have it's own id. random-number-generator-service should have one id (even when it runs in a web farm).
RandomNumberConsumer.exe is installed on different machines outside the domain, so should have a unique id per installation.
A client has nothing to do with a user as the sub claim is missing. The only time the client includes the sub claim is when it acts on behalf (and with consent) of the user. This can be the case for random-number-generator-service, but not for RandomNumberConsumer.exe where there is no user interaction (as it is a Windows Service) and consent is not needed as it is given when the user requested the installation.
When you are talking about a Windows Service then it is inevitable to configure the service. You can however implement configuration steps in the installer. So instead of having to build UI or hacking a configuration file, you can take the following approach:
User requests an installation of the program. When approved a client is created and attached to the tenant (ClientClaims), based on the user.
The user starts the download of the installer and receives the id/secret (on screen, email).
User starts the installation and in one of the steps the user has to enter the id/secret. This is acceptable since it is quite common when installing software.
This has the advantages you want and takes minimal steps from the user.
If the service has more configuration options and you want to give the user a UI to maintain the options then add a configuration program to the installer. This is quite common for routers and printers. There is no need for the user to login as it runs local (localhost website). You can add a link for the browser as shortcut.
We have a website deployed with Impersonate=true.
A connection string is defined as this:
Integrated Security=SSPI;Persist Security Info=false;Initial
Catalog=MyDatabase;Data Source=MyServer;
I assume Persist Security Info is redundant as that only applies to SQL authentication? We need to use integrated security as can't have passwords in the config file due to corporate security policies.
The website runs under a service account. The service account has permissions to access the database, but other accounts do not have access (security policy).
The problem we're facing is the user account is being passed to the database and being rejected, due to Impersonate=true.
We're required to have Impersonate=true for a Single Sign-On component to work.
Is this a catch 22 or is there a solution?
I hope I've written this clearly enough!
As per http://msdn.microsoft.com/en-us/library/134ec8tc(v=vs.80).aspx
"Impersonation is independent of the authentication mode configured using the authentication configuration element. The authentication element is used to determine the User property of the current HttpContext. Impersonation is used to determine the WindowsIdentity of the ASP.NET application'" Accordingly, you do not need to enable impersonation to be able to authenticate users. Note however that your application will have to handle authorization. A ready framework to implement authorization is NetSQLAzman, see http://netsqlazman.codeplex.com/
I'm working with an MVC application on a test server that used to work perfectly. It creates accounts on a server that a 2nd application uses for logging in. It uses a credential store and PrincipalContext and UserPrincipal objects to create these accounts.
I haven't used the test version of this app for months or possibly almost a year. Now when I go to create an account with the application, I get the following error:
Access is denied.
ASP.NET is not authorized to access the requested resource. Consider
granting access rights to the resource to the ASP.NET request
identity. ASP.NET has a base process identity (typically
{MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6 and IIS 7, and
the configured application pool identity on IIS 7.5) that is used if
the application is not impersonating. If the application is
impersonating via , the identity will be
the anonymous user (typically IUSR_MACHINENAME) or the authenticated
request user.
To grant ASP.NET access to a file, right-click the file in Explorer,
choose "Properties" and select the Security tab. Click "Add" to add
the appropriate user or group. Highlight the ASP.NET account, and
check the boxes for the desired access.
I looked at anonymous access, but the production version of this app also has a rule to deny anonymous access and it's working fine. This application never used impersonation even when it was working and I've heard that granting explicit access to ASP.NET is not generally recommended. I can make the application work locally through Visual Studio, but the version deployed to test continues to give this error. I would rater not republish the site to test, but perhaps that's the only option left? Is there anything obvious (but not to me) that could have changed in the security settings to cause this? I'm still researching with no luck.
Thank you!
You need to provide a service account to your ApplicationPool Identity that has the appropriate level of access. When you're using the Studio, it uses your user account for access so it's almost a given. When the application is installed onto IIS it uses the lowest possible level of access available, and that simply isn't enough. It isn't recommended that you open it wide up, but establishing a limited access service account for this specific purpose will allow the application to function without having to compromise system or personal accounts.
I am working on an C#.NET application for handheld devices with Windows CE 2003, these devices connect to a web service, hosted on a local web server, for connection to database.
Problem I am facing: I have to keep web service directory security as Anonymous because handheld device cant be authenticated from AD and thats why I cant use windows authenticated security settings.
Can anyone suggest me how do I ensure security of web service having anonymous security??
Cheers :)
I have to keep directory security as anonymous for pocket pcs to use the webservice, but we can control these permissions by granting access on the basis of IP addresses through IIS. For this just go to IIS and right click on web service folder and go to properties. Then in derectory security tab, IP address and domain name restrictions section provides this functionality of restricting users on the basis of their IP or domain.
I hope it will help others too.
Cheers.