4 ms·

> How easy/hard is it for a developer? If one is targeting any SAML compliant IdP, then this would be very hard and painful unless the developer chooses to use

> How easy/hard is it for a developer? If one is targeting any SAML compliant IdP, then this would be very hard and painful unless the developer chooses to use a mature library that preferably provides high level APIs to handle the request generation and response handling. > How about setting up an identify provider in dev? The easiest way is to not setup one in dev by oneself, but use free instances (potentially unstable at times) provided by the likes of Okta (okta.com) and other cloud based services.

rkeene2 7y ago
I've written a simple SAML IdP[0] which could be used for development purposes -- it's overall not too complex to deal with. Maybe I should release this whole thing so people could have a simple SAML server for testing... though I'd probably switch to a better XML parser ! :-) [0] http://www.rkeene.org/viewer/tmp/tcl-saml.tcl.htm http://www.rkeene.org/viewer/tmp/tcl-saml.tcl.htm (there's a web front-end that goes in front of this package to take the HTTP request turn it into the appropriate username and call this library).
- rkeene2 7y ago
  Here it is as a service that will just send you a signed SAML assertion for any username given. IdP URL: https://rkeene.dev/saml-idp-1/ https://rkeene.dev/saml-idp-1/ Metadata: https://rkeene.dev/saml-idp-1/metadata.xml https://rkeene.dev/saml-idp-1/metadata.xml
neilv 7y ago
Agreed, coding "from scratch" to use a SAML IdP would be painful for a typical developer, who thus far mainly has experience using Web/app frameworks. And, as with much software development, it's easy to introduce vulnerabilities. Use off-the-shelf, if you can. That said, I've had to implement several SSO protocols "from scratch" (using off-the-shelf libraries for HTTPS, XML, and crypto) for a large Web system, including at least a couple different SAML IdP variants. There was a lot of figuring things out, and being very careful, and it was difficult but useful experience. (The SAML IdP uses were reasonable for authentication, and simply worked. Where I saw trouble was when cleanroom implementing client side of some of the non-standard SSO protocols used by some large companies. Every time I discovered a security problem with a customer's protocol design/implementation, I had to go to the director I was working with (fortunately, a very smart engineering PhD, who took it seriously), then he had to explain to the customer. Presumably there were historical and/or requirements reasons for doing a non-standard protocol, but security is hard, and every programmer changing the code is potentially a weak link.)

rkeene2 7y ago

I've written a simple SAML IdP[0] which could be used for development purposes -- it's overall not too complex to deal with. Maybe I should release this whole thing so people could have a simple SAML server for testing... though I'd probably switch to a better XML parser ! :-) [0] http://www.rkeene.org/viewer/tmp/tcl-saml.tcl.htm http://www.rkeene.org/viewer/tmp/tcl-saml.tcl.htm (there's a web front-end that goes in front of this package to take the HTTP request turn it into the appropriate username and call this library).

rkeene2 7y ago
Here it is as a service that will just send you a signed SAML assertion for any username given. IdP URL: https://rkeene.dev/saml-idp-1/ https://rkeene.dev/saml-idp-1/ Metadata: https://rkeene.dev/saml-idp-1/metadata.xml https://rkeene.dev/saml-idp-1/metadata.xml

neilv 7y ago

Agreed, coding "from scratch" to use a SAML IdP would be painful for a typical developer, who thus far mainly has experience using Web/app frameworks. And, as with much software development, it's easy to introduce vulnerabilities. Use off-the-shelf, if you can. That said, I've had to implement several SSO protocols "from scratch" (using off-the-shelf libraries for HTTPS, XML, and crypto) for a large Web system, including at least a couple different SAML IdP variants. There was a lot of figuring things out, and being very careful, and it was difficult but useful experience. (The SAML IdP uses were reasonable for authentication, and simply worked. Where I saw trouble was when cleanroom implementing client side of some of the non-standard SSO protocols used by some large companies. Every time I discovered a security problem with a customer's protocol design/implementation, I had to go to the director I was working with (fortunately, a very smart engineering PhD, who took it seriously), then he had to explain to the customer. Presumably there were historical and/or requirements reasons for doing a non-standard protocol, but security is hard, and every programmer changing the code is potentially a weak link.)