I am looking to implement single sign-on within an Elixir project, that will act as the SAML service provider.
The identity providers will be exposed in Azure AD, and I have some questions on how to get started (no prior Elixir experience).
I have looked at Samly and Hangar by handnot2 but I am not sure if that is the best approach, considering that the library doesn’t seem to have been updated since 2017. I know the flow for SAML SSO, and what to set up in Azure enterprise application and sso for the service provider once it has been set up in Elixir, but I’m not really sure how to go about the setup of SAML service provider in Elixir.
Any feedback/advice is welcome.
I’ve used Samly with AAD. The active GH repo is now here, that’s where the Hex package appears to come from, and it was updated in March of this year.
The samly hex package has been forked, due to inactivity, and now is up to date…
I am using samly with OTP25, and Azure AD idp
I just implemented my own saml callback controller/action in Phoenix. Took about 30 mins (i.e. pretty easy), but I used the
ruby-saml gem as reference. We also use Azure IDP.
Good to know about Samly!
Thank you for the replies
Glad to see you guys have set up it previously - I assume that this approach as initially thought for implementation with Elixir is alright?
Add Samly library to the project, set up SAML Service Provider, the metadata values for EntityID and Reply URL (Assertion Consumer Service URL) should be supplied to the partner who will then set up Azure AD Enterprise Application with SSO and register our application using the EntityID and ReplyURL.
Performing a SAML request, we then wait and process the SAML response using Samly and validate it, if validated against our certificate the user is then granted access to the page they requested.
As for the session, the flows will be triggered/initiated by the user on the Service Provider end -
Do I need to store anything of the SAML response?
Samly defines a Samly.State.Store behaviour and two implementations: Session and ETS. So it’s pretty easy to customize, for instance to write the assertion to a ‘sessions’ table in your DB, associated with a user record. You can then build on that to implement session revocation (proper sign-out), “last sign in” message, role based access controls, etc.
You could also put your application behind Apache HTTPD (acting as a reverse proxy) and use the Apache Shibboleth SP module to handle SAML - carefully pass attributes back to your application as HTTP headers.
I would not recommend using Shibboleth. It’s one of the banes of our team’s existence…
It’s massively over engineered for seemingly no reason, and a relic of the pre-containerized age. We’re actively trying to get our clients off Shibboleth and onto just plain SAML.