Use the most battle-tested, well-supported SAML service available, even if it's more pain up-front; something that documents what XML canonicalization and signature algorithms and crypto suites it supports, so you're not dead in the water upon encountering a federation partner that requires encryption, or claims filtering and transformation, or whatever.

The federation service should live outside your app(s); app(s) trusts your fed server only, and the fed server manages trust relationships with third parties, handles stuff like claims mapping; apps should be architected to understand that user information has been somehow added to the request context, but isolated from the mechanism, and ideally not expect to have an external source of user state.

Get comfortable with the protocol over HTTP; capture the exchanges, decode the payloads.

Just do it and see what happens ¯\_(ツ)_/¯

Most certainly use a library at least for building and parsing messages. All the complexity is in figuring out how to use your particular library and figuring out any quirks in the systems your connecting re: what fields and formats they expect. It's not really something you can read up on and then know before you start

you don't really go and implement saml, you deploy saml. you pick one service depending on your preferred language and go with it.

I've worked both with apereo cas (java, was called jasig or something like that then) and simplesamlphp and they managed across multiple proprietary dialect with minimal effort, so those are good starting point