Difference between revisions of "Release Notes v1.94"

From
Jump to: navigation, search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
There were several feature requests and enhancements made in version 1.94 that are worthwhile.  Some of the underlying .NET libraries were updated as well.  
+
There were several feature requests and enhancements made in version 1.94 that needed to be addressed.  Some of the underlying .NET libraries were updated as well.    
 
 
==   ==
 
  
 
== Technology Updates ==
 
== Technology Updates ==
  
The following updates were made and have no impact in functionality.  The web.config does have to be updated in existing entries to ensure that the new versions are used.  
+
The following updates were made and have no impact in functionality.  The [[Upgrading_v1.93_to_v1.94|web.config]] does have to be updated in existing entries to ensure that the new versions are used.  
  
 
=== Maintenance Item 2020-01-09-A<br/> Upgrade to MVC 5.2.7 ===
 
=== Maintenance Item 2020-01-09-A<br/> Upgrade to MVC 5.2.7 ===
Line 21: Line 19:
  
 
=== Problem Ticket 2019-12-17-A ===
 
=== Problem Ticket 2019-12-17-A ===
<div><br/> Support for special case of having an AD group that includes "Domain Users" as a member.&nbsp;</div> <div>This is a unique scenario and something that the .NET directory objects don't handle all that well since "Domain Users" is the primary group of 99.99% of the users in AD (except when admins make changes).&nbsp; As such it does not exist as a group member when placed in group.&nbsp; Technically adding "domain users" to any groups tends to superfluous since that means that (typically) all users will be a member of the group and may as well be better server by assigning the "Domain Users" group.&nbsp; Nonetheless, the scenario does exist and now the code will look for that special condition.</div>  
+
<div><br/> Support for special case of having an AD group that includes "Domain Users" as a member.&nbsp;</div> <div>This is a unique scenario and something that the .NET directory objects don't handle all that well since "Domain Users" is the primary group of 99.99% of the users in AD (except when admins make changes).&nbsp; As such it does not exist as a group member that can be enumerated recursively when placed in group.&nbsp; Technically adding "domain users" to any groups tends to superfluous since that means that (typically) all users will be a member of the group and may as well be better server by assigning the "Domain Users" group.&nbsp; Nonetheless, the scenario does exist and now the code will look for that special condition.</div>  
 
Note: this is an expensive operation since that group will be looked specifically and adds additional overhead.&nbsp; You need to enable this (new) parameter:
 
Note: this is an expensive operation since that group will be looked specifically and adds additional overhead.&nbsp; You need to enable this (new) parameter:
 
<pre>PrimaryADGroupCheck="true"</pre>
 
<pre>PrimaryADGroupCheck="true"</pre>
  
=== &nbsp; ===
+
&nbsp;
  
 
=== Feature Request 2019-07-22-A ===
 
=== Feature Request 2019-07-22-A ===

Latest revision as of 20:46, 23 February 2020

There were several feature requests and enhancements made in version 1.94 that needed to be addressed.  Some of the underlying .NET libraries were updated as well.    

Technology Updates

The following updates were made and have no impact in functionality.  The web.config does have to be updated in existing entries to ensure that the new versions are used.  

Maintenance Item 2020-01-09-A
Upgrade to MVC 5.2.7

Maintenance Item 2020-01-09-B
Clean build folders

Maintenance Item 2020-01-09-D
Upgrade to EntityFramework 6.3

Maintenance Item 2020-01-09-F
SQLite upgrade 1.0.112

 

Enhancements and Feature Requests

Problem Ticket 2019-12-17-A


Support for special case of having an AD group that includes "Domain Users" as a member. 
This is a unique scenario and something that the .NET directory objects don't handle all that well since "Domain Users" is the primary group of 99.99% of the users in AD (except when admins make changes).  As such it does not exist as a group member that can be enumerated recursively when placed in group.  Technically adding "domain users" to any groups tends to superfluous since that means that (typically) all users will be a member of the group and may as well be better server by assigning the "Domain Users" group.  Nonetheless, the scenario does exist and now the code will look for that special condition.

Note: this is an expensive operation since that group will be looked specifically and adds additional overhead.  You need to enable this (new) parameter:

PrimaryADGroupCheck="true"

 

Feature Request 2019-07-22-A


Feature request for permissions if the GroupName is "*" then it will apply to all users and will not actually check against directory server; good for global rules.
In some scenarios where UserContextMode 4 (and 5) is used, the administrator may wish to grant (or deny) users access.  Using the "*" (asterisk) in the group permission elements will assign the Allow/Deny rule automatically without invoking the directory server which speeds up performance.
      <Domains Description="Everyone" DomainName="corporate" GroupName="*" Action="Allow"/>

 

Feature Request 2019-08-20-A


Force purge STS session cookie after redirect to Service Provider.
Although the .NET session by default is set to 2 minutes, there is no need to maintain the session if the users has been redirected to the Service Provider.  At that point, there is no need to have the session maintained and good security hygiene would suggest that the session be terminated.  While no confidential information is stored in the session cookie, having a valid cookie leaves the exploit of replay attacks and impersonation a feasibility.

Organizations using UserContextMode 4 (and 5) are potentially impacted since the session cookie is used to store the source parameters while the user is authenticated, and as such should be tested before enabling in Production.

ClearSession="true"

 

Feature Request 2020-01-20-B


More granular token time out per service.

Each SAMLConfigurationElements now allows the administrator to specify a token timeout value specifically per service provider.  This is useful when the service provider needs a higher tolerance (e.g. due to network latency or other processing delays).

      <SAMLConfigurationElement Service="ConnectingGTA" AssertingParty="sts.federation.uat.hospital.on.ca" EncryptSAML="false" <span style="color:#c0392b">TokenTimeSpan="2"</span>

 

Feature Request 2020-01-20-C


Update telus14, ehealthontario141 and ehealthontario15 profile logic for UAO assignment. 
 
A a specific condition in a multi-UAO value provided by Cerner systems due to technical limitations has been handled differently ("|" will be used instead of "," as delimiters).

 

Problem Ticket 2019-09-19-A


Add event of INFO type in Logs to capture username and usercontext mode.

When Debug mode was turned off there was no adequate logging of the actual user context information in the STSLog file.

 

Feature Request 2019-09-19-A


Add Service item to audit file. For organizations using the same instance of STS for different Service Providers, an additional field has been included that indicates the service invoked. Note that this field has been added to the end of each line in order to not impact existing audit scripts/process that expect the same fields in the same order.