We're having a hard time figuring how these credentials objects work. In fact, they may not work how we expected them to work. Here's an explanation of the current issue.
We got 2 servers that needs to talk with each other through webservices. The first one (let's call it Server01) has a Windows Service running as the NetworkService account. The other one Server02 has ReportingServices running with IIS 6.0. The Windows Service on Server01 is trying to use the Server02 ReportingServices WebService to generate reports and send them by email.
So, here's what we tried so far.
Setting the credentials at runtime (This works perfectly fine):
rs.Credentials = new NetworkCredentials("user", "pass", "domain");
Now, if we could use a generic user all would be fine, however... we are not allowed to. So, we are trying to use the DefaultCredetials or DefaultNetworkCredentials and pass it to the RS Webservice:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
Or:
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
Either way won't work. We're always getting 401 Unauthrorized from IIS. Now, what we know is that if we want to give access to a resource logged as NetworkService, we need to grant it to DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx):
Granting Access to a Remote SQL Server
If you are accessing a database on another server in the same domain (or in a trusted domain), the Network Service account's network credentials are used to authenticate to the database. The Network Service account's credentials are of the form DomainName\AspNetServer$, where DomainName is the domain of the ASP.NET server and AspNetServer is your Web server name.
For example, if your ASP.NET application runs on a server named SVR1 in the domain CONTOSO, the SQL Server sees a database access request from CONTOSO\SVR1$.
We assumed that granting access the same way with IIS would work. However, it does not. Or at least, something is not set properly for it to authenticate correctly.
So, here are some questions:
We've read about "Impersonating Users" somewhere, do we need to set this somewhere in the Windows Service ?
Is it possible to grant access to the NetworkService built-in account to a remote IIS server ?
Thanks for reading!
All details you need are included in this very old article
In short, when you find it confusing to troubleshoot issues like this, you should first review the technical details behind ASP.NET impersonation carefully.
Here are some things you could check out:
- set an SPN (Service Principal Name) for the reporting service; you can find good examples in google;
- Allow delegation (ClientCredentials.Windows.AllowImpersonationLevel)
Is the problem that you're failing to authenticate to IIS, or failing to authenticate to SSRS? The DOMAIN\MachineName$ account may need to be granted permission in SSRS to run the report you're trying to automate.
SSRS usually does a pretty good job of getting IIS configured correctly, so you shouldn't need to mess with those settings. I double-checked my installation (which is SSRS 2005, things may have worked differently in SSRS 2000 and you didn't say which version you're running), and it's set to use Windows authentication and has impersonation enabled. That means IIS should basically just be authenticating your credentials (validating a correct username/password), not authorizing (determining whether that user has permission to run the report in question). IIS then passes the credentials on to SSRS, which has its own settings for determining what accounts have permission to view reports.
Also, you can automate sending reports on a scheduled basis directly in SSRS, so you may not need the Windows service at all if your scheduling is fairly basic (i.e., daily, weekly, etc.).
Related
Having WSO2 IS 5.0.0.SP1 backed by PostgreSQL there is another application reading user information using the SCIM service (filter=userNameEq...)
All works but after certain time the service returns "User is not authorized.." response with a single ERROR level log line. Since that moment all subsequent calls fail with "404 User is not authorized". Even when I log in using the admin account I have no access rights. This state takes for a few minutes and then all seems working again.
We traced the response message to the SCIM service implementation where the authorization is checked. However we are unable to find the root cause of the issue (suspecting some exception is qietly dropped, cache cleanup cleans more than it should, ...)
Any hint / idea is appreciated.
Carpe diem
Gabriel
This seems to be authorization issue. If after trying 3 fail login attempt user locked 0-minutes(Most user used 05 minutes). This is default settings of fresh WSO2 IS pack. After the configured locked-time user unlocked. Then the user have a login with valid credentials. If you need, you can change the login attempt,locked time.Please check [IS_HOME]/repository/conf/security/identity-mgt.properties file. It's having the all configuration.
Issue is resolved (or - reason is identified in another system). In the AD tree one of the domain controllers is external (cloud) and unable to authenticate the technical (wso2) datastore user. When the AD node hostname is resolved to the cloud node, then ldapsearch is unable to return any groups from a sub-domain of the cloud based domain controller (interesting - it doesn't fail).
I have a Bluemix web application (Liberty for Java), which implements some web services. These web services should be called from a mobile application (Android). I have now secured this web application by binding it to the Bluemix Single Sign On service (SSO) with a cloud directory created in the SSO service. Using the web app from a web browser works fine; but, I have problems obtaining an access token from the SSO service, which would allow the mobile application to invoke the services.
From the OAuth2 specification (IETF RFC 6749), I figured that the appropriate way of doing this would be the "native application" profile with a "public client" (as specified in Clause 2.1 of the OAuth2 Spec) using the "password" grant type (OAuth2 spec, Clause 4.3 "Resource Owner Password Credentials Grant").
I used the Spring for Android framework for this purpose, and code for this would look like this:
ResourceOwnerPasswordResourceDetails resourceDetails =
new ResourceOwnerPasswordResourceDetails();
resourceDetails.setId("dtu-se2-e15-cloud-directory");
resourceDetails.setAccessTokenUri(APP_SSO_API_ACCESS_TOKEN_URI);
resourceDetails.setClientId(APP_SSO_API_CLIENT_ID);
resourceDetails.setClientSecret(APP_SSO_API_CLIENT_SECRET);
resourceDetails.setGrantType("password");
resourceDetails.setScope(Arrays.asList(SCOPE));
resourceDetails.setUsername(USERNAME);
resourceDetails.setPassword(PASSWORD);
OAuth2RestTemplate restTemplate = new OAuth2RestTemplate(resourceDetails);
restTemplate.getMessageConverters().add(new MappingJackson2HttpMessageConverter());
UserPosition newPosition = restTemplate.postForObject(
POST_POSITION_SERVICE_URI, position, UserPosition.class);
But, I don't think that this code matters, and ultimately made my experiments with obtaining access tokens directly with curl:
Actually, I tried using two different clients with different OAuth2 token endpoints:
I created a client (and client credentials) in the Cloud directory, that I had created in the Bluemix SSO service. And I tried the OAuth2 Token Endpoint URI and the created client credentials. But it appears that this endpoint does not support the grant type "password" at all. It appears that this client is not considered a public client by the endpoint.
I also tried the credentials and OAuth Token Endpoint URI for the Web application itself (which I looked up in the VCAP_SERVICES environment variable). This end point seems to support the grant type "password"; but all variants of requests I could think of, kept responding: invalid_resource_owner_credential.
As I said, I used curl to try out many different variations of requests to these
token endpoints:
used the token endpoint URI of both the SSO services with the web app credentials
as well as the one created in the cloud directory API Access
tried GET and POST (did not make any difference)
tried Content-Type: application/x-www-form-urlencoded and
Content-Type: application/json (both of them seemed to work with the same effect)
providing the client_id only (which always was unsuccessful)
providing the client credentials in the body or parameters, as well as
authenication information in the header (actually, I do not like the idea
of providing the client secret to the Android app, but I tried that too);
as user name, I tried the name as I had created it in the web browser redirection
when registering a new user; but I also tried the user name which the Principal of
the security context of a request would provide (when successfully invoking
a service from a web browser with the user logged in); I even tried the principal's
accessId (non of these worked, I always got: invalid_resource_owner_credential)
used different scopes, and none at all
None of the above (and different combinations of that) would result in a successful
response and an access token for the user. The "best" I could get was a response
invalid_resource_owner_credential (making me believe that at least the client was
accepted in some situations).
Unfortunately, I did not find many things that could be configured concerning client
access (and public clients, in particular), and I did not find much documentation on
which subset of the OAuth2 protocol (grant types and profiles) is supported by the
Bluemix SSO service and the attached cloud directory.
Can anyone could tell me how to authenticate with a Bluemix web application
(Liberty for Java) from a mobile app (Android) as a public client or how to set
up the Bluemix web app and the SSO service to which it is bound so that this is
possible. In case it would matter, I am working with Bluemix in the "US South"
region and under an IBM Academic Initiative membership account for Bluemix.
I would prefer a solution, where the mobile app would not need to know the client
secret, but if this is the only way to make this work for now, adding the client
credentials to the mobile app would be OK.
I would appreciate any help with this problem, thanks in advance,
Ekkart
Bluemix has a mobile-specific service called Mobile Client Access that could help to facilitate security for your mobile app. To read about it, log into Bluemix and look for it under the Mobile category. To ask questions about it here, use or search using the [bluemix-mobile-services] tag.
I developed a webapplication Example1:7575 which uses FBA. Now, I deployed these WSP's to a new server Production:2525 to get the same functionality of my previous server's webapplication. However, I was not able to fetch the data from sql server and I'm getting the following error: A Membership Provider has not been configured correctly. Check the web.config setttings for this web application.
Actually, I have manually entered the same membership and role providers of my previous server's central admin, security service token & web application's web.config entries to this new web.configs and matched them.
Can someone help me with where I might be doing wrong. Any help would be greatly appreciated.
If you can't fetch data from SQL Server there's probably an issue with permissions to the database. Check the database connection string that FBA is using. It likely uses Windows authentication to connect - in which case it will be connecting as the user assigned to the app pool for the web application and the secure token service. Check that the configured app pool identities have permissions to access the sql server databases.
I need to create an application for a company and they would like to have people login to the application to have different permissions to perform different tasks.
My initial idea was to create a MySQL database, hardcode the credentials into the application and have the application connect to the MySQL database. The MySQL database would then have a table called "users" which would store usernames, passwords and permissions. The application would then query the server and perform the authentication.
The biggest problem with this is having the MySQL credentials hard coded into the application. If the application gets into the wrong hands, they could do lots of damage to the MySQL database if they snoop around to find the credentials and start dropping tables.
So I thought of developing a server that acts as an interface for the MySQL Database. For example, the client application would connect to the Server via TCP, and the server connects to a MySQL database. That way the MySQL credentials are never exposed to end-users. However, this means I have to develop a server application which a) will be harder to maintain and deploy for my customer (as opposed to just setting up a MySQL Server) and b)Has potential to introduce more bugs since I have an additional system I need to make (which relates back to point a for deploying bug fixes, etc)
So I was thinking instead of having a table of users in the database and having the application connect directly to the MySQL server with hardcoded credentials, the end-user would be given actual MySQL user credentials in which they would enter into the application to connect to the MySQL server. This means if someone gets their hands on the application, they can't do any damage to the MySQL database, but there still remains the risk of an end-user giving their credentials to the wrong person.
What are the best ways to have a desktop application connect to a MySQL database? Are there any other solutions other than the 3 I have thought of, or do you have any thoughts on my solutions?
As #Perception noted. Your best bet here is to implement a web service in front of MySQL. You don't want unknown numbers of clients from unknown IP addresses all having access to your database.
It would be really easy to DOS attack you by tying up MySQL connections. Not to mention that you would very severely limit your ability to scale your backend service to meet the demands of an increased client base without having a web service in between.
The web service could also offer you the ability to control user authentication and authorization in any number of ways (user/pass combination, token-based access, OAuth access, etc.).
Where I work there are two practices I have seen:
Each entity (person, thing, or business (depending on level of granularity needed) accessing the database) has their very own credentials. This was used on an MSSQL and on a Rocket Universe database. This is mostly the retail and legacy software.
We host the application ourselves and use a separate authentication system for users. The database credentials are stored on our server where the application is hosted. The client knows nothing of the backing database. These are usually web apps and web services.
Something you could do that we have done is that many of our applications actually talk through a RESTful service that emulates the database in a way. The application itself has no access to the database. I would read the wikipedia article on restful services for more information. Our authentication is done using Nonce encoded HMAC requests where each user is given their very own key tied to their credentials.
Wrapping the database in a web service gives you a few possible advantages:
If you decide to change your database structure while keeping the same information, you might not even need to update the client applications, just the service.
Credentials never leave the server, your credentials remain safe so long as nobody gains access to your server. Security in general is increased.
If you do your service cleverly enough, you could even transfer much of the internal logic that would normally be client side onto the server, making updates and bugfixes virtually seamless to the client.
The disadvantages that I see:
It is one more thing to maintain
Your application is vulnerable to denial of service attacks, but since it is a database that's a possible problem anyway
If the server goes down, all the client applications go down, but again, still a problem anyway.
RESTful architecture: http://en.wikipedia.org/wiki/Representational_state_transfer
HMAC: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code
Our HMAC system works like so:
User logs in using username and password to their local application.
The local application communicates to our authentication service and gets a "Session Key" and shared secret for that username and password.
Using the Session Key (which expires in a short period of time), the application creates an API Key (which lasts a long time) and stores it to the computer. The session key could be used instead of an API Key if the user is required to log in each time. We mainly did it this way for convenience for some programs. If the computer is not secure, the Session Key should be used only and no API key is stored on the local machine. Each time the user logs in, they get a new Session Key.
Each request to the database service is accompanied by a HMAC-signed nonce which the application gets from the authorization service based on the API key. After getting the nonce, the application signs it using the shared secret. These signed requests can only be used once since the web service (which the user could know nothing about) authenticates the request. Once the signed nonce has been authenticated server-side by seeing if hashing the nonce with that particular API/Session Key's shared secret results in the same digest, the nonce is marked expired and the request is granted.
The above is vulnerable to man-in-the-middle attacks if HTTPS is not used, so often people make a message based on the nonce and the URL being requested along with a timestamp and compute the HMAC on that. The server then recreates the message based on the URL, checks to see if the timestamp is within some bounds (+/- 4mins or something), and then authorizes the user based on that information.
To further granulate operations, we also have a role system which checks to see if the user who owns the Session/API Key has been given permission to request the thing that they were requesting. If they have the appropriate role, the request is granted.
Summary: Credentials are done user-by-user, the end user has no knowledge of the database, a web service wraps the database in a RESTful API, and a role based system is used to make permissions granular.
This is just a suggestion and I am not saying this is the best or only way to do this. This just happens to be how we have ended up doing it where I work.
Let's look at two ways of dealing with database:
Client directly connects database, and manipulate database
Server connects to database and provide interface for client to use
Considering your use case:
valid valid serial number or to store/read information about certain user
it can be designed in the following way to provide security. (I'm no expert in this)
Client directly connects database, and manipulate database
You don't have to use your admin to visit database, instead you create a user for client only, and limit user's access privilege to only viewing (certain data). And you can enforce security policy at database by changing privilege for this user.
you can consult MySQL :: MySQL 5.1 Reference Manual :: 6 Security for more info.
6.2 The MySQL Access Privilege System
6.3 MySQL User Account Management
Server connects to database and provide interface for client to use
You can use HTTP and provide interface to client to use. And only the backend connects to the database.
Something like RESTful API, there are many easy to use framework that provides authentication and authorization.
I don't think it's good idea to let client have direct access to database in your case. So if possible, the second option is better.
Also note that password based authentication is not ideal.
Case 1. When I browse a little test site from my own PC called JOHNXP (e.g. http://localhost/WebClient ), my .aspx page invokes my ASMX webservice picks up my credentials and passes them across to another webservice on ANOTHER machine (SERVERTRIM) in the same domain. I can see my request resulting in a Security Log entry on the SERVERTRIM machine with my credentials.
Case 2. I move to another PC in the same domain and logon with the same credentials I used back at my personal desktop. When I browse the same test site above (this time as http://johnxp/WebClient ), I get this percolated back to my .aspx page:
System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Net.WebException: The request failed with HTTP status 401: Unauthorized
Looking at the Security Log on SERVERTRIM, I note that the access in case 2 resulted in an ANONYMOUS LOGON which seems to explain the 401 / Unauthorized.
I'm trying to get my webservice to use the credentials of the logged in DOMAIN user when my WS calls a vendor's webservice on a different server.
My ASMX webservice runs on my desktop (IIS 5.1 WinXP Pro - machine name is JOHNXP). I have Enable anonymous UNCHECKED in every server involved and I have this in every web.config involved in my scenario:
The vendor webservice runs on SERVERTRIM (Win 2003 Server) and it is also ASMX and uses WSE 3.0.
Wireshark and Netmon look too formidable as tools for me right now. I am figuring the different resulting LOGONs on the "remote" server (SERVERTRIM) are sufficient "evidence". All machines above are in the same domain but I want to keep the "remote" webservice on SERVERTRIM and my intermediate webservice on a different server in the same domain if possible. Does this scenario demand that I have to dig into "delegation"? What would be the easiest tool to monitor why the same credentials result in an ANONYMOUS LOGON when the web request is initiated on another machine in the domain?
My knowledge of authentication is a bit hazy, but if I understood your description correctly:
in the first case, you're browsing to localhost, which is impersonating the caller, then calling a web service on a different machine. The impersonation is being done on the same machine as the client. I believe in this case, the impersonating application doesn't need to be on a machine that is trusted for delegation (because it's already the same machine as the client).
in the second case, you're browsing to a different PC, which is attempting to impersonate the caller when calling a third PC. In this case, the PC in the middle would need to be trusted for delegation (which it presumably won't be if it's a development workstation).