Microsoft's Enterprise SSO server is bundled with BizTalk Server - I'm fairly familiar with how to configure it, make sure it's working, etc. My questsion is, what exactly does it do, and how does it do it?
My best understanding is that it is used to securely store configuration for things like ports and adapters, because configuration items often include things like credentials, passwords, connection strings, etc. In terms of "how it works", my best guess is that the configuration values are stored encrypted in an SSO database, and the "master secret" is simply the encryption key that only privileged credentials (like the one running the BizTalk hosts) have access to, so they can use it to access the encrypted configuration.
Can someone shine some light on this and point out where this is right/wrong?
You're pretty close overall. EntSSO is used by BizTalk internally to store any sensitive data. This includes particularly the adapter-specific part of any send port/receive location configuration.
But that's not all EntSSO does; it can also be used to provide credential mapping services between Windows and non-windows systems, by storing sets of encrypted credentials for other applications and mapping within them. Basically, this can be used to provide single sign-on services when building BizTalk solutions so that BizTalk can "act as" a specific user when doing stuff on their behalf.
For example, you could have BizTalk receive a message over an HTTP/SOAP receive location set up with Windows Integrated authentication, and then let BizTalk flow that authentication information over to an FTP send port where the Windows user credential is mapped to a specific username/password combination associated to it so that BizTalk can authenticate as said user to the FTP server. With this, different Windows Users sending messages to BizTalk would result in separate FTP connections created with different credentials on the other end (this is different from the default BizTalk behavior of using a single credential for all operations on a send port).
Obviously EntSSO offers a bunch of other options beyond this, but that's kinda the big deal.
BTW, the BizTalk docs actually contain a fairly extensive section on EntSSO that is pretty useful.
Related
Let's say I want to set up a poor man's authentication scheme for a simple network service.
I don't want to bother with username/password authentication, for simplicity I just want to have a list of public keys in my application and anyone who can prove they are the owner of that key can use my service.
For the purposes of my application it would greatly simplify the authentication process since all my users are on the local network and they all use Unix. Anytime I onboard a new user I can just ask them for their ssh public key.
Is there a simple way to reuse the mechanism involved in ssh public key authentication in a non-ssh application? This is question is intended to be language agnostic.
If you just have a list of users that can use your application and you have no need to see who did what.
You can setup your server so that it listens only on localhost (127.1) rather than 0.0.0.0, and provide a restricted sshd, forwarding the port required to connect to the application
~/.ssh/authorized_keys will provide a list of the authorized keys that can be used.
ssh -I private_key_file <hostname> -L 3000:localhost:3000
For a basic setup and help with configuring your sshd, check out this answer:
https://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-port-forwarding
Note: Be warned that if you don't lock it down, any user will have full shell access on your box where the machine is hosted.
A dirty hack from top of my head: could you wrap the application so that it would create an actual SSH tunnel from localhost to your server, and use that for ?
Assuming you are talking about a web based application. What you are really looking for is X.509 Client certificates (1.3.6.1.5.5.7.3.2). This will allow you to identify a user individually to your application.
These face the same issues that are usually faced when looking at key distribution. Which is generally considered a hard problem.
If you wanted to head down this road here is what you would need to do.
Generate a root certificate (once)
Setup web server with appropriate modules to parse the certificate (nginx/apache)
Generate a certificate for each user (openssl)
Download cerificiate from centralized server. (maybe use their ssh pub key here)
Install the x509 cert locally (OS Dependent)
On the server side, you would need to process the cert as part of the web-server (nginx or apache should have modules to do this) and then pass the name onto your application as a header field which you can then process internally.
This is a much better security solution than usernames and passwords, however is complex because of the key distribution issue. Most people wouldn't bother since in most applications it is easy enough to integrate logins with LDAP or radius.
I have seen variations of this question but couldn't find any that dealt with our particular scenario.
We have an existing aps.net website that links to a SQL Server database.
The database has clr user-defined types, hence it can only be hosted in Azure VM since Cloud Services don't support said types.
We initially wanted to use a vm for the database and cloud service for the front-end, but then some issues arose:
We use StateServer for storing State, but Azure doesn't support that. We would need to configure either Table storage, SQL Databases, or a Worker role dedicated to State management (a new worker role is an added cost). Table storage wouldn't be ideal due to performance. The other 2 options are preferable but they introduce cost or app-reconfiguration disadvantages.
We use SimpleMembership for user management. We would need to migrate the membership tables from our vm instance sql server to Azure's SQL Databases. This is an inconvenience as we want to keep all our tables in the same database, and splitting up the 2 may require making some code changes.
We are looking for a quick solution to have this app live as soon as possible, and at manageable cost. We are desperately trying to avoid re-factoring our code just to accommodate hosting part of the app in Azure Cloud services.
Questions:
Should we just go the VM route for hosting everything?
Is there any cost benefit in leveraging a VM instance (for sql server) and a Cloud Service instance (for the front-end)?
It seems to me every added "background process" to a Cloud Service will require a new worker role. For example, if we wanted to enable smtp for email services, this would require a new role, and hence more cost. Is this correct?
To run SQL Server with CLR etc, you'll need to run SQL Server in a Virtual Machine.
For the web tier, there are advantages to Cloud Services (web roles), as they are stateless - very easy to scale out/in without worrying about OS setup. And app setup is done through startup scripts upon bootup. If you can host your session content appropriately, the stateless model will be simpler to scale and maintain. However: If you have any type of complex installations to perform that take a while (or manual intervention), then a Virtual Machine may indeed be the better route, since you can build the VM out, and then create a master image from that VM. You'll still have OS and app maintenance issues to contend with, just as you would in an on-premises environment.
Let me correct you on your 3rd bullet regarding background processes. A cloud service's web role (or worker role) instances are merely Windows Server VM's with some scaffolding code for startup and process monitoring. You don't need a separate role for each. Feel free to run your entire app on a single web role and scale out; you'll just be scaling at a very coarse-grain level.
Some things to consider...
If you want to be cheap, you can have your web/worker role share the same code on a single machine by adding the RoleEntryPoint. Here is a post that actually shows how to do what you are trying to do with sending email:
http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx
Session management is painfully slow in SQL Azure DB, I would use the Azure Cache if you can..it is fast.
SQL Server with VMs is going to cause problems for you, because you will also need to create a virtual network between that and any cloud services. This is really stupid, but if you deploy a cloud service AND a VM they communicate over the PUBLIC LOAD BALANCER causing a potential security concern and network latency. So, first you need to virtual network them (that is an extra cost)..then you also need to host a DNS server to address the SQL Server VM. Yes this is really stupid, unless you are OK with your web/worker roles communicating with your SQL Server over the internet :)
EDIT: changed "public internet" to "public load balancer" (and noted latency)
EDIT: The above information is 100% correct contrary to the comment by David below. Please read the guidance from Microsoft here:
http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario
DIRECTLY FROM MICROSOFT GUIDANCE speaking about cross Cloud Service communication (VM->web/worker roles):
"We recommend that you implement the first option as the connection process would not need to go through the public Internet. Therefore, it would provide a better network performance."
As of today (8/29/2013) Azure VMs and Worker/Web Roles are deployed into DIFFERENT "Cloud Services". Therefore communication between them needs to be secured via a Virtual Network that exposes private IP addresses between the instances.
To follow up on David's point below, that about adding an ACL. You are still sending packets over the internet using TDS (SQL Server protocol). That can be encrypted, but no sane architect/enterprise governance/security governance would "allow" this scenario to happen in a production environment.
I've been looking around and haven't been getting very far in my research of WCF security. I have a low-risk service I want to create so I just want some basic security required for client's on different servers outside of the domain to be able to use it.
What's the easiest way in WCF? Is it just through the use of certificates?
Check this, it covers many security scenarios, use whichever suits your need.
And for authentication purpose you can easily opt Username security, where you just need to pass user name and password.
Easiest way to simply encrypt the transmission is if you're just using net.tcp binding, then you can turn on Transport security or Message security without needing to set up a certificate.
With WsHttpBinding message-level security (contents of the message are encrypted) is enabled by default and doesn't require an SSL cert. And if the clients are on the same Windows network then it'll use Windows Authentication and credentials by default, too, so you should be able to enable Transport security without needing an SSL cert there, either.
If you want to expose your service over HTTPS to the public internet then you'll need to obtain an SSL certificate and bind it to the port on the server that the service runs on, using httpcfg.exe (comes with Windows Server).
Im implementing my own RPC framework and well moste of the stuff is done but i need some help how do i verify a auth_unix? the structure of the data is definied in http://www.faqs.org/rfcs/rfc1050.html 9.2 UNIX Authentication but how should i verify the user?
UID and GID are compared to the UID and GID on the server to validate their authenticity. These IDs can be shared across unix systems using NIS or some other facility. Anything subsequently executed on the remote system is run under that effective UID and GID.
The application behind the server may implement further authentication, but note that AUTH_UNIX does not authenticate the user in itself; it trusts the UID and GID supplied.
From Section 9.3:
9.3 DES Authentication
UNIX authentication suffers from two major problems:
(1) The naming is too UNIX oriented.
(2) There is no verifier, so credentials can easily be faked.
DES authentication attempts to fix these two problems.
If you use Unix authentication you can only assume that the message originates from a trusted host and some mechanism was in place to authenticate the user before they got the chance to do something that originated the call.
In this case it would be up to the application to verify user credentials. The originating machine name is also supplied so you could make sure that the originating IP address matches it and only reply to that address - this has obvious vulnerabilities to DNS cache poisoning attacks. Also, making this play nicely with DHCP or NAT is left as an exercise to the reader ;-}
Which means you have little choice but to trust the UID and GID or do additional verification within the application sitting on top of your RPC library. The RFC discusses more secure authentication mechanisms. However, Sun RPC is not the most secure of protocols and is generally not recommended for services provided to untrusted clients.
I'm in a process of designing a multi-tier ASP.NET web application that is supposed to deal with sensitive information (say financial data).
I would like to identify all potential threats the application will face in real life and plan the countermeasures accordingly.
Some details:
The application will be hosted in customer's data center for both internal and external users
Target platform is Windows Server 2008 + IIS7 or Windows Server 2003 + IIS6
Target DB is MS SQL Server 2008
Phew! Where to start... Depends on how "secure" you need it to be. i.e. Difference between a personal blog and a large project for a large company/government dept. etc...
In no particular order
Secure your configuration files by encrypting them.
Ensure that your Database is behind some sort of DMZ and not on a publically accessible IP
Get a security company to give your site an overhaul for potential vulneribilities (Cross Site Scripting / Sql Injection)
Use SSL
Lock down everything port-wise on the server except for 80 HTTP & 443 HTTPS unless absolutely necessary
Make sure your Remote Desktop/VNC connections to the box are secure
If your storing passwords in the DB, hash & salt them and don't store plain text
Publish your code, and don't leave source code on the server
Build your code based on known standards, i.e. don't write your own Crypto Algorithms
If secure connections between the Site->DB or Site-MSMQs are available, use them
Microsoft have a good article on securing ASP.NET apps that i'll dig out.
Edit
And as Syed just posted in his reply, (+1 a credit to him)
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication
http://msdn.microsoft.com/en-us/library/aa302415.aspx
for multi layer security.
http://msdn.microsoft.com/en-us/library/aa302415.aspx#secnetlp_part3
that is a very large (broad) question, there are complete books on security that can not answer that. Go to Borders and get a few security books and start reading.