SSIS Authentication Model: SQL Authentication vs Windows Authentication (Windows Integrated Security)

Hello,

I am in the process of defining a SQL authentication mode model for SSIS package development.  I am proposing to eliminate SQL mixed mode based authentication COMPLETELY and to solely utilize Windows authentication (Windows Integrated Security) as our SQL Server authentication type.

Are any of you working at SSIS heavy shops where you only utilize Windows based authentication for SQL Server access?

From a security standpoint, utilizing solely Windows authentication within a SQL environment has many advantages.

I am now in the process of identifying the impact this security model would have on the development, maintainability, scalability, and performance of SSIS packages.

Particularly, I am concerned that with the elimination of SQL based authentication, overall development time and complexity of SSIS packages will greatly increase.

Consider the following example.   I develop highly N-Tier conforming SSIS packages in which one main SSIS package would call several data flow packages in order to segregate units of functionality.  This chain dependency of SSIS packages allows for easy maintenance and testing within a production environment.

A typical SSIS package I develop can be viewed in the following manner:

[Main Package 1] ---> [Business Logic Layer Package] --->  [Individual Data Flow Package]

As one can see above, one SSIS package calls another SSIS package, which finally calls another.

Now, as anyone would, I would schedule SSIS package execution using SQL Server Agent.  This being said, using the example above, if I had 5 data flow packages being executed within my main SSIS package that reference 5 different data sources, for security adherence, I could create 5 separate SQL authentication based users within SQL Server so that only the needed permissions are granted to each user used with each of the 5 data flows.

Now, if I were to eliminate SQL Server based authentication, the process becomes difficult as I would only be able to use Windows Integrated Security for authentication.

Now, being that I will continue to desire to assign a custom set of SQL based permissions to each user utilized within the 5 data flows above in our example, the only way I can see being able to assign a custom user to each SSIS data flow using the Windows authentication model for SQL Server would be to use "Credential" and "Proxy: objects as discussed here:

However, this solution presents a problem in that I cannot assign a unique Windows user to execute each of my 5 SSIS packages as only one SSIS package is actually going to get scheduled by SQL Server Agent. 

Being that one SSIS package calls other SSIS packages, unless I am mistaken (please correct me if I'm wrong) I can only set the "run as" Windows user at the SQL Server Agent job level and not at the SSIS package level like I want to.  This would limit my SSIS package being executed as one user, which is not what I desire security-wise. 

Is there any way you know of to be able to specify the exact Windows user each of the 5 SSIS packages in my example would be executed as?

If not, please consider my proposed idea to create a "hybrid" approach to this security issue:

1. SQL Server would be configured to support "mixed mode" authentication.
2. One Windows authentication based user would be created on SQL server that would be used as the "Run As" user when scheduling the main SSIS package via SQL Server Agent.
3. 5 seperate SQL Server authentication based users would be created on SQL Server for each of the data flow packages.
4. Each of the 5 SSIS packages would be developed to store the individual SQL Server authentication based connection strings on a centrally located SQL Server table.
5. Only the "Run As" Windows authentication based user that the entire set of SSIS packages are running as would be granted select only access to this "SSIS package parameters" table.
6. During execution time, each of the 5 SSIS data flow designated packages would authentication to SQL Server FIRST via Windows authentication in order to access the SSIS SQL "parameters table".
7. Each of the 5 SSIS data flow designated packages would then access the parameter table and grab its unique SQL authentication based connection string and apply this connection string to its corresponding data flow task objects.
8. All ETL operations would then be performed by the data flow designated SSIS packages using the uniquely assigned SQL authentication based user within each data flow package.

This solution above has the following benefits:

1. No connection information including user names and passwords are stored in plain text within the SSIS environment via XML config files.
2. Each SSIS package can only access SQL connection string information from the "parameter table" ONLY if the Windows user the SSIS package is currently running as is granted sufficient permissions.
3. SSIS package development is not overly bloated and cumbersome as individual SSIS data flow designated packages can still use package configurations to easily configure data flow tasks, not adding unnecessary development efforts to existing development workflows.

What do you think about my solution?  Is this a feasible solution for an enterprise environment?  Do you think this approach adheres to a solid set of good security practices?

I am open to all suggestions on how I can tackle this problem with security and ease of development being number one priority.

I would greatly appreciate your input on this!