I've actually done this implementation. We've used it quite reliably for many years. At one point I'm sure I was one of the loudest voices in the "SAML must be integrated in with Archibus" crowd.
However - we're actually moving away from that and moving to request-header auth instead. It just makes more sense (for us at any rate) to offload all of that authentication to our ADC, the same way we're having our self-hosted clients offload that piece to Shibboleth-SP.
Really, it somewhat depends on how Archibus intends to be delivered as a product. In the current world, there's typically entire architecture that surrounds an Archibus install - it's not just a standalone windows .exe installer. You'll need Java, Tomcat, a Firewall, etc.
So today the more *modern* approach, imho, is actually to utilize that architecture for your authentication service provider. i.e. the current recommended approach of using Shibboleth.
Scott Kelly
shared this idea
·
I've actually done this implementation. We've used it quite reliably for many years. At one point I'm sure I was one of the loudest voices in the "SAML must be integrated in with Archibus" crowd.
However - we're actually moving away from that and moving to request-header auth instead. It just makes more sense (for us at any rate) to offload all of that authentication to our ADC, the same way we're having our self-hosted clients offload that piece to Shibboleth-SP.
Really, it somewhat depends on how Archibus intends to be delivered as a product. In the current world, there's typically entire architecture that surrounds an Archibus install - it's not just a standalone windows .exe installer. You'll need Java, Tomcat, a Firewall, etc.
So today the more *modern* approach, imho, is actually to utilize that architecture for your authentication service provider. i.e. the current recommended approach of using Shibboleth.