Landing SSO

#beginners #programming #opensource

Landing the beginning to the SSO work

This week I spent the majority of my time working on OSD trying to address the comment on my PR #236 for the first bits of a working SSO flow using Samlify and Remix, partly based on this repo.

This PR addressed the following issue and then maybe a little more.

The initial scope of the issue was to add a SAML server to the project in which I would configure the SP and the IDP. The IDP would be configured using the XML data that the SimpleSAMLPHP container we use in production provides. At first this was fetched from an endpoint that exposes the XML, the route that we fetched it from was saved as an environment variable. After a few iterations upon my initial commits this became us reading the file from a local secrets folder in DEV where I had copied and pasted the pertinent XML, these secrets will be configured through Docker Swarm Secrets. The SP on the other hand was created within our code using the constructor that Samlify provides, setting the redirect and post bindings directly in the code.

David made the comment upon his first review that the SP and IDP objects need not be known by the rest of our program, meaning that it would be best if we did not have to export these from SAML server and into whatever other files would be using Samlify functionality. Instead what I ended up doing was I created functions that made use of the SP and IDP objects within the SAML Server file and exported functionality in that way, using only those Samlify API That I knew I would need.

There was also the issue of keeping the route to redirect to after logging in, this was achieved through the RelayState query parameter that seems to be a standard part of SAML.

This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection

The relay state is often used in IDP initiated SSO so that the IDP actually can signal to the SP what URL it should redirect to once successfully signed on, in our case the flow is SP initiated but it makes it easy for us to take the redirectTo query param from remix and append it to the SAML request as a relayState and from there it persists through the whole flow, coming back in the response body when the SAML response is posted.

There were several parts of my code that could use a guard clause and I refactored my code as such, this is something I should probably keep in mind as we go forward along with some typescript functionality I learned this week through reading some of Denes and Won's code where they use TypeScript operators like the ! on functions, or the pick utility type that allows for the construction of a type by picking only the desired attributes from other types using the union |.

David also taught me about narrowing a type down by using the as keyword which helped me directly in my code when using it to narrow down FormDataEntryValue to a string, along with being reminded to use the URL methods when constructing more complex paths instead of relying on string concatenation.

These are all things that I should keep in mind moving forward when reviewing but I am afraid they will still slip my mind regularly even as I am coding.

Being a sheriff

This week was my first being a sheriff. I don't think I did the worst job but I could have been more active than I was particularly in reviewing PRs. I think when it came down to it I reviewed two of them, one of Chen's and one of Won's although I just made a comment about starchartdev still being used as the user and I don't know how helpful that is, I should have followed up further.

This week we did not have a first weekly meeting due to Family day and so I took to Slack to remind everyone to commit to some work and be ready to talk about it later in the week and to be active on Slack if they required assistance with blockers.

In the Wednesday meeting I did a quick run down of the team's current goals and whether they had any blockers which is customary now, and David reminded me to get commitments on those folks who had outstanding PRs for landing them, we also set a new hard deadline for PRs to be reviewed which is as of now noon on Friday every week. Afterwards David lead the class in an example PR on Denes's Let's Encrypt code and as I mentioned I learned some TS syntax during the demonstration.

I think to be more effective as a leader I need to get more familiar with the libraries we are using. It does not come easy to me to review Let's Encrypt or the DNS Route 53 code, I think I am going to have to make a concerted effort to learn and become comfortable with these things and it seems like a lot to take in. That being said as the demo on Wednesday highlighted there are many parts of a PR that can be reviewed without express knowledge of the details, whether something is well commented, whether guard clauses are being used as I have come to know, whether there is an else in a conditional after a return, a lot of more common concerns.

Next Steps

I still have a lot to do with the SSO part of Starchart which makes me wonder how I'll be able to become more familiar with Let's Encrypt and the DNS stuff, essentially the bulk of our logic to what the site seeks to achieve, while I am going to get into trying to get SSO to work with the Staging IDP and Metadata, and I seek to ensure the validity of the responses through signatures that I have yet to really successfully configure along with the concern of logging out (which David has suggested we should perhaps not do SLO and instead just kill the session). I am contributing but I don't know if quite enough yet, and whether I am really doing the role of sheriff justice.