Difference between revisions of "Release Notes v1.94"
Thewikiadmin (talk | contribs) |
Thewikiadmin (talk | contribs) |
||
(2 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 | + | 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. </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). As such it does not exist as a group member 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.</div> | + | <div><br/> Support for special case of having an AD group that includes "Domain Users" as a member. </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). 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.</div> |
Note: this is an expensive operation since that group will be looked specifically and adds additional overhead. You need to enable this (new) parameter: | Note: this is an expensive operation since that group will be looked specifically and adds additional overhead. You need to enable this (new) parameter: | ||
<pre>PrimaryADGroupCheck="true"</pre> | <pre>PrimaryADGroupCheck="true"</pre> |
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.
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.
<Domains Description="Everyone" DomainName="corporate" GroupName="*" Action="Allow"/>
Feature Request 2019-08-20-A
Force purge STS session cookie after redirect to Service Provider.
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.
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.