Orbital Lite STS v1.95 Notes

Introduction   This is intended to be a preview of the capabilities and functionalities planned for v1.95.  These may change based on feature requests or identified issues that need to be prioritized.   The primary goal with v1.95 will be to prepare the solution for technology growth primarily in the following items:

• transition from the older .NET 4.51 framework to a newer version of .NET Core,
• preparing for SSO and supporting existing IDPs,
• caching more data to improve performance
• moving away from the archaic web.config file that is used for configuration. 

What will be missing in this version will be a large amounts of new functionality as the intention will be to ensure that the codebase remains fairly unchanged to ensure that there are no disruptions with current integrations.   

 

The move to .NET Core is to update the various framework libraries that go as far back as 2013 which have been kept to minimize disruption for existing systems.  The intention since v1.8 is to maintain the same .NET framework version and there hasn't been anything so far that could not be accomplished with it.  Moving to .NET Core also positions the STS for a more light-weight deployment which would lend itself well for containirization so that cloud deployments can be OS agnostic and use resources more efficiently.  It's not that the STS has a large footprint but this will ensure that the solution continues to be very lean.

 

In regards Cloud-deployments it should be kept in mind that Windows Integrated Authentication uses Kerberos behind the scenes which may not be feasible for orgenizations that maintain their domain controllers on-premise.  In the short-term a cloud-deployment is feasible for environments that use UserContextModes 1 and 2 and have well-defined or LDAP dependencies.  Long-term UserContextModes 6 and 7 will extend the federated authentication model whereby the STS solution will effectively become more of a SAML generator.  

 

While the STS is quite well-performing in terms of processing requests, there are additional improvements that can be made in regards caching information.  At the moment the primary candidate is the group membership code.  In some cases these groups can contain thousands of users and can take 100s of milleseconds to retrieve.  This would provide a significant performance benefit although the memory footprint may be increased (albeit a small price to pay).
In addition there are many (too) frequent configuration file checks that can be avoided and moved to memory instead.  

 

Another aspect that needs to be addressed is that STS configuration will be moved away from the web.config to a new dedicated repository.  The web.config formatting is quite rigid and it's apparent that the STS has outgrown its confined structure.  Upgrades have been more complex than they should have been and have required more manual interventon than desired by both the client and RWI.  This may be the time to explore adding a central DB support although the admin interface will need to be introduced.

 

With respect to reporting, more organizations are moving towards central repositories either for SIEM, auditing or business metrics, v1.95 will introduce some basic reporting focused on providing security incident reports (i.e. report on all activity for a user) and dashboard on activity (number of users, errors, performance, etc).  

 

This will also be last version that will have support for UserContextMode 3.  It was an initial implementation that was flawed from a security perspective and was added to support some more limited implementations.  Since 2013/2014 no organization has selected this option since the other options are more secure and simpler to implement.  It will also simplify the QA process for each release and free up some testing cycles to prepare for the SSO integrations. Overall, the vast majority of organizations are using UserContextModes 2 and 4: https://wiki.radiusworks.com/main/customcontent/usercontextmodes-breakdown.jpg

 

Also, v1.95 will be final version where Windows 2012 R2 will be actively supported and tested against.  Few organizations remain on Windows 2012 servers and the ones that still have their STS running on 2012 R2 are planning to migrate to a newer version.  Keep in mind that Active Directory functional level has no direct impact to STS regardless of the UserContextMode and the directory calls.  The main reason for discontinuing support for Windows 2012 R2 is to allow v1.96 to implement a newer version of the .NET 4.6.2 which is included as part of the OS components.