Forem: sfrunza13

1.0 Release!

sfrunza13 — Thu, 20 Apr 2023 23:44:05 +0000

My.Custom.Domain 1.0 (mycustomdomain.senecacollege.ca)

This week marks the conclusion of a semester long journey to deliver our opensource DNS and SSL certificate solution named My.Custom.Domain or Starchart. This Wednesday the team got together and watched David release the first real production build of the site and I had the honors of creating the PR for that release from main to the release branch. Unfortunately I had messed up and the changelog did not actually contain any changes (more on that in a second) and on top of that the site was acting a bit funny.

Staging was working perfectly fine so after a bit of digging we decided that it must have been some of the AWS variables that ITS handed us that must have been wrong, David fixed that and the DNS records were working as intended but a unique constraint on the Order Urls were causing problems within the cert flow so a quick setting of orderURL to null upon update so that duplicate requests do not break things was done #652.

Now back to how I messed up.

Where are my changes logged?

To create a changelog upon release I had added an action to the release.yml which was supposed to create or update a tag named release and then find the differences between the previous release tag commit and the current release tag commit and generate a changelog of commits from that difference. This worked upon an initial attempt to release because the action was actually making the difference between the HEAD and the newly created release tag since there was no previous release tag at the time. Fast-forward to Wednesday and our release, the action does not work, I go into the action to see what is happening and it claims that there are 0 new commits from the last release tag, impossible I say! I don't know for a fact what was happening here but I suspect that since the name of the branch that initiates this workflow is also release the action got confused between the sha merged to the release branch and the sha of our last release tag. I tried replicating this in my own test repo and was able to actually run into the exact same problem.

My solution was pretty simple, I changed the name of the tag to be something other than "release", in this case I changed it to "latest". Afterwards it worked:

As has been the case with quite a few of my PRs thus far, the solution was a single word difference #657.

Concluding what is likely my last semester at Seneca...

...in this way is hilarious. A one word PR. Ha!

But on a more serious note I am really proud of this website, of the great people that I have worked with and learned from in this class, and very grateful that I could have this kind of experience thanks to David who is also responsible for the other courses that I think have most influenced me in how I think about developing: the previous open source course and the cloud computing course.

I don't really know how to wrap this up, my experience with Seneca has really pleasantly surprised me and today I am happy and proud to hopefully be a future alumnus.

Thank you to everyone.

Git Actions

sfrunza13 — Sat, 15 Apr 2023 00:30:33 +0000

This week in Star Chart

We are nearing the 1.0 release of star chart and a lot of the big ticket items are done, the site really seems as though it is coming together and we even deployed it to production.

Initially we intended to deploy to production every time we pushed a v Tag for a new version of star chart and have an action run that would automate the release and change log for that new version tag. We tried testing this and found that we had some problems with permissions which will be a common theme this week although for a different reason later and we decided instead to create a release branch. The releases will be done by merging the appropriate version of main into the release branch and that will trigger the release to prod. What I did is I got an action working that will automate a changelog, creating a release tag with the release and taking all of the new commits from this release tag to the previous one and documenting them in a change log for the new release.

This was achieved using the following action: Action!. Initially this was what I intended to use to automate releases on pushing version tags but it also worked for this. The problem I ran into was the following:

 Generating release tag
  Attempting to create or update release tag "release"
  Could not create new tag "refs/tags/release" (Resource not accessible by integration) therefore updating existing tag "tags/release"

I realized that it was a permissions problem but could not figure out at a glance what permission I was missing and this wasn't really documented in the action docs so I eventually found my way to Github Docs. I made an educated guess as to which of these subheadings we would need by matching what I saw in the error to a similar looking git api. After adding permissions to the yml file to write content the next release worked and generated a change log:

PRs: #563, #590, #609

Finishing Impersonation

sfrunza13 — Mon, 10 Apr 2023 14:45:48 +0000

Finishing impersonation

This past week my issue of choice when working on the Starchart (My.Custom.Domain) opensource web site was the following to broadly "make impersonation work" #508. The week before last I had gotten the logic I wanted to use for this issue landed in terms of how it would work on the session/root loader side of things and I replaced every place I could see at the time that was using the useUser hook to take a user out of the root loader with my new useEffectiveUser hook which would do the same but would allow for admins to impersonate other users and act in their stead.

Reconciling code differences

For the majority of this week's work I ended up working as is often the case in another developer's code, and saw some things that I have not seen before. I had already seen the way that this dev had written simple button posts using useFetcher from Remix and thought that was cool, I tried using it before myself although I don't remember if it ended up in any of my PRs, and after taking a while to remember how our components, routes, actions and loaders worked together I dove into the code in our admin pages.

When writing my own code this time I stood true to what I had done before and kept what I knew worked moving forward so when I was writing the logic for the buttons on the admin table that should impersonate a user I used the same kind of logic I had done before where I wrapped the buttons in a form with an invisible input and made them of submit type.

Once the buttons to submit were clicked the action for the admin route would be reached with my payload and there was already code on this route using something I had never seen before.

The dev I had mentioned created this cool bit of code that would search through users as you entered characters into a search box, and on the "back end" (the action) they used a typed approach to their response using a library that is new to me called Zod. I tried to use Zod for quite a while and parse the payload as I was seeing, I added a new attribute to his parseFormSafe call and tried to make it conditional/optional seeing as my newEffectiveUser would not always be in the payload to the action but it didn't work the way I had hoped and was taking a bit longer than I was comfortable with at the time with the other obligations I have at the end of the semester. It turned out the best way I could think of doing it was to actually make the search logic and the impersonation logic mutually exclusive. First I would write the cave man way I have been writing the actions where I just try to extract something from the request's formData with a .get and if what I expect is there then I redirect to index with the effective user cookie populated with the new value from the button press and if not then we must have arrived here from the search box and so ensue the previous logic.

Tying up loose ends

In this PR I also added requireAdmin to the admin route, I changed another one of pages from useUser to useEffectiveUser and I also did some changes to the way the header looks whenever an admin is impersonating someone so that it would show a theater mask and allow you to stop with the press of a newly added button in the header that worked similarly to how the impersonation button worked, that is to say a form submit that results in a redirect with a new cookie.

The full PR is here #547

Patching and Pretending

sfrunza13 — Tue, 04 Apr 2023 01:33:40 +0000

This week in Starchart

Here is my weekly run down of developments on my end to do with the Starchart project which is an open source project that has long since been renamed My.Custom.Domain (which I will not be calling it, because we are astronomers here) for students at Seneca College to be able to hone their skills while also delivering a website that can be used to generate certificates for some domains that might not be https for some reason cough load balancers cough.

This past week I worked on an issue to mock users if you are part of the admin group (the chosen few) and that can be found here. It was not the biggest code change but it was so dizzying trying to keep track of what I was dealing with between the session, the root loader and the database especially after I looked away from the project and focused on something else entirely, often written in a different language. This last week rolling into this one has given me a different perspective on focus as a finite resource with how many different directions I seem to be pulled in.

It was also brought to my attention shortly after my code landed that staging was broken and David had already had the problem pretty well figured out so I dropped what I was doing to put in a small PR to change the undefined value that was causing us problems to a null value since null is valid in Java Script Object Notation. The Fix marked Starchart's 1st PR past 500!

Looking forward

Today marks a new beginning and the last week before we get going on Alpha for Starchart, as such we had a stand up where we took a look at every one of the open issues, even the ones we have already assigned and redistributed them more evenly, as well as highlighted the immediate tasks to take care of in this final sprint.

Now that we are just pre-alpha we are also going to start bringing in more collaborators to begin testing our work without instruction to see if what we have created is friendly for new users.

Who stole the cookies from the...

sfrunza13 — Mon, 27 Mar 2023 14:01:59 +0000

Last week in Starchart

In the last week I was a part of a few extra meetings alongside the regular team stand ups for our open source project Starchart, a meeting at the start of the week to discuss the new SLO implementation with David where we arrived at a neater solution for the SLO cookie and made it strict and restricted it to the logout route. At the same time we made the session cookie strict, I had forgotten what I had seen when looking at telescope's cookies. We also made some UI changes to the logout prompt making a less prominent button that would initiate SLO and a more vibrant red one that would just redirect you to sign in having only invalidated the session cookie with the starchart website. In any case, I was able to land the new SLO flow at the beginning of this week after some discussion and then demonstrated in a consequent mid-week meeting with the team PR #366.

I also did a few reviews, although here I will only mention one of them since I felt I added a bit more to this PR than others PR #414.

Cookie problems

Here we have the impromptu bug that refreshed my memory on one of the problems with cookies when doing SSO. When my SLO change was incorporated into staging it seemingly broke something when signing in, making it so that a user would have to sign in twice to be authenticated to Starchart. My first instinct was to check the networking tab and to take a look at the cookies because I remembered we set the session cookie to strict and lo and behold the session cookie was being rejected since the browser claimed it set as a result of a cross-site request. The browser was of course correct, the session cookie is set on our login callback as a result of a request from our IDP which is a different origin and indeed cross-site, since we set the session cookie to be strict it would not be set by any cross-site requests at all. The simple solution here was to set the cookie to lax instead of strict and allow it to be set as a result of a cross-site request and this seems to be the general consensus when it comes to SSO seeing as session cookies are very often set as a result of a callback from an entity separate from our website. We did however keep the SLO cookie as strict since it really only exists and needs to be used within the one logout route that I have written within our own application. In any case here is the one word PR that fixed our double login issue PR #427

Next Steps

Next I need to take a look at allowing admins to impersonate users in Starchart which I should do by adding information to the session, an "effective user" field that will come empty for admins so that they can set it to who they would want to impersonate and that would come forcibly filled with a regular user's own username so they can not in fact impersonate anyone else.

Reworking SLO

sfrunza13 — Mon, 20 Mar 2023 02:02:35 +0000

Reworking Logout

A few times

This week there were a few small PRs that I landed for our opensource project Starchart / My.Custom.Domain worth mentioning:

343 Which took out the SLO portion of our app in favor of just ending the session with Starchart
356 Which is a small change because the groups claim can come back as either an array or a string which was not something we were aware of and this fixes that. This is pretty important now as we're rolling things out into staging and need to give everyone the opportunity to log in but the change is small.
385 A version bump for the app to match the release notes for 0.6

TD and I also reviewed and merged a first time commiters PR for a simple typo here: 378.

I also gave a presentation on Wednesday about how my SAML code works, what the IDP and SP are, how their metadata is configured, the important parts of the configuration (the certificate, signature, claims and the assertion consumer service bindings) and how to follow along with the key requests in the SAML flow that have to do with what we send and what we receive at our callback.

The rest of the week's efforts on Starchart were spent on adding Single Logout back into the program and I have done it a few ways now.

The first time I gave the user a page with two buttons that were choices to either logout of Starchart or logout of all Seneca services, the review on the initial PR was that the session should automatically be destroyed and then the choice should be given to SLO. I decided to put my logout page under index because I wanted the pretty header to render with my buttons, this caused some problems here because destroying the session meant we had no user information any longer which meant the header could not render display name and if the user would choose to SLO we had no idea which user to SLO.

My first solution to get around this was to use global variables to keep track of the user that logged out while they were making their decision. It was later brought to my attention that globals won't work because they can't keep track of multiple clients usernames so I changed it to use cookies instead.

I added a redirect to the function that destroys the session and added a cookie for it to return with the username, in this way we can redirect to the logout page again and the loader can check for that cookie and use it as the value to send to the SLO request when the button's pressed and the post sets off the action to create the SLO request.

I made the username in the header optional although I think following recent discussions I will just move the logout page so it will not have the header since that improves clarity.

The PR discussed above is here: 366

David and I also tried out staging a bit and each created an a record that works to redirect to an EC2 instance he stood up.

Successful SAML

sfrunza13 — Sun, 12 Mar 2023 03:59:39 +0000

Testing

This week was the first coming back from the reading week break and I had a few clear cut objectives coming into it. The first thing that I wanted to accomplish was to create an e2e test for the authentication flow that I have added to the open source starchart project. The library that we use for e2e testing is playwright, and using it is actually pretty easy. The corresponding issue for the creation of the test is here. Initially there was a speed bump seeing as the playwright scripts were written to run with a different port but David looked into it and came to the conclusion that using 8080 should be fine and after that change my e2e tests passed CI PR#1 to my branch.

I learned after I was done with creating my test that it is possible to use a plugin to easily record things but doing it how I did it was not far off, instead of using a pretty plugin I just ran the dev server in one console and I ran an npx command in another: npx playwright codegen localhost:8080. This looks a little wonky seeing as for some reason the CSS does not quite take on this browser that is used for recording tests but in any case it makes writing tests easy because you can practically do what you want to test and it records the playwright syntax that would re-produce your actions on the specified URL (in this case localhost:8080). Here's how it looks:

along with a console that allows you to pick elements out of the page and start and stop recording along with a real time view of the playwright syntax you are recording with your actions:

Something similar to the auth test that I wrote in #294 was later used as a dependency for the rest of the e2e tests in a PR written by Eakam #313.

This is a video from the playwright devs showing off project dependencies, what was used in #313. https://www.youtube.com/watch?v=PI50YAPTAs4

Staging SAML

The second order of business this week was to bring the local idp I set up more in line with the staging idp by actually testing our SAML in staging and seeing what claims we get back from Azure AD and then taking those claims and configuring our simpleSAMLphp local idp to return the same claims.

David tasked me with gutting starchart so that all that was left was the SAML logic basically and so that is what I did. Then after the second meeting of the week we got on a call and took my butchered branch to staging after I pushed it as an image to dockerhub so that he could run a container of it.

There was a problem that I did not understand when we got to trying to run it, to solve it David pulled up the files in the build folder and added logging to key points where our IDP was being used to find that despite us setting the IDP in an init method when the code called for its use it was undefined. This was the impetus for the changes to the init logic that David had setup the weeks prior in #321. The change towards loading the idp metadata from a file turns out to also be the recommendation from a security perspective as well apparently as mentioned here.

After fixing the issue we were able to see what the response from the actual Seneca IDP would look like:

{
   "attributes":{
      "displayname":"Stefan Frunza",
      "email":"sfrunza@myseneca.ca",
      "group":"mycustomdomain-dev-students",
      "http://schemas.microsoft.com/claims/authnmethodsreferences":"http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password",
      "http://schemas.microsoft.com/identity/claims/identityprovider":"https://sts.windows.net/eb34f74a-58e7-4a8b-9e59-433e4c412757/",
      "http://schemas.microsoft.com/identity/claims/objectidentifier":"61e8ee88-bd7c-453f-be1d-f11778b7c191",
      "http://schemas.microsoft.com/identity/claims/tenantid":"eb34f74a-58e7-4a8b-9e59-433e4c412757",
      "sAMAccountName":"sfrunza"
   },
   "audience":"https://mycustomdomain-dev.senecacollege.ca/sp",
   "conditions":{
      "notBefore":"2023-03-08T20:39:18.590Z",
      "notOnOrAfter":"2023-03-08T21:44:18.590Z"
   },
   "issuer":"https://sts.windows.net/eb34f74a-58e7-4a8b-9e59-433e4c412757/",
   "level":"info",
   "message":"Saml Response",
   "nameID":"bwNMtMWvOf99rmm1zCSelnfkgSOijBEQubNe0G7Ir58",
   "response":{
      "destination":"https://mycustomdomain-dev.senecacollege.ca/login/callback",
      "id":"_295e9f6d-abeb-41ae-bef4-10b4112c8bb1",
      "inResponseTo":"_bf26e2ce-93f6-4816-8ad9-cb74629f80e1",
      "issueInstant":"2023-03-08T20:44:18.767Z"
   },
   "sessionIndex":{
      "authnInstant":"2023-03-08T20:44:17.232Z",
      "sessionIndex":"_920c1410-15fe-44be-ac98-70d17cb73000"
   },
   "timestamp":"2023-03-08T20:44:20.906Z"
}

I was also able to take some snapshots of our great victory:

The work we did here allowed Chen and I to rework the user model and simpleSAMLphp config in the following #312 #307

Looking forward

I noticed that the routing is deprecated and slated to change to flat routes and opened the following issue #320.
I also opened an issue to do with how we plan to handle admins, in that the admins are meant to be able to assume control of regular user accounts and so there should be an "effective username" field as well #306. The effective username should come in empty only for admins and the rest of the users should have that field be populated with their username.

Landing SSO

sfrunza13 — Sun, 26 Feb 2023 23:58:47 +0000

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.

Failing Forward

sfrunza13 — Mon, 20 Feb 2023 02:35:24 +0000

This week was a big one for the authentication part of starchart, or it should have been.

I started this week by taking up an issue I had written to add a SAML Server that configures the Identity Provider and the Service Provider objects from SAMLIFY with the appropriate metadata and settings and although the authentication flow seems to work I kind of doubt that it really does.

This week started with me pulling from the Offical SAMLIFY docs and the Remix SAML example. I got the authentication process to work but I did not add signature requirements or validation of signatures, and I was also importing the sp and idp objects and exposing them in every file where there was supposed to be some SAMLIFY logic, and I also fetched the idp xml metadata from the endpoint the simple saml php container exposes it on, I changed this in a consequent commit so that we have the file locally and read it using fs, all of this is kind of subject to change and that is the essence of the problem.

This week I got my PR in on Thursday, which is pretty late, especially considering there was an influx of other PRs that would come in on the weekend as well, for a PR that has as many problems as mine does (currently 46 comments and probably more to come), the weekend is not enough time to sort it all out and land it properly. So one of the take aways from this week is to either make smaller PRs or get the PR up earlier in the week, in any case be more pro-active.

Now about failure

My code has a lot of problems, for example I keep on missing potential simplification by adding guard clauses on my conditional logic and I exposed the IDP and SP when I could have kept the SAMLIFY objects localized to a file and only exported functionality, and there are a bunch of other things like not to put else conditions after returns which I did on some of my redirects.

Apart from these better coding practices I am failing to fundamentally achieve my goal in understanding exactly how to get this SAML process to work. I initially thought that I wanted every request and response signed, then I thought that I just want my assertions from the IDP signed, then I realized more recently that those are not being signed despite me specifying in the SP config that they ought to be because in the extract there should be an additional signature attribute for claims I believe.

Something like this:

{
  samlContent: "<samlp:Response ...",
  extract: {
    audience: "https://sp.example.org/sso/metadata",
    attribute: {
      email: "user@esaml2.com",
      lastName: "Samuel",
      firstName: "E"
    },
    conditions: {
      notbefore: "2015-10-26T11:41:43.500Z"
      notonorafter: "2015-10-26T11:46:43.500Z"
    },
    issuer: ['https://sp.example.org/sso/metadata'],
    nameID: "user@esaml2.com"
    signature: "<Signature ... </Signature>",
    statuscode: {
      value: "urn:oasis:names:tc:SAML:2.0:status:Success"
    }
  }
}

https://github.com/tngan/samlify/blob/master/docs/saml-response.md

Granted our extract looks really similar, the signature field wasn't there last I checked.

EDIT: Upon closer examination we might be getting it signed actually, I was only looking at the extract but the signature is not WITHIN the extract object, I will double check this soon. Could it be that I am too quick to write off what I make as bad? Tune in in 20 mins to find out.

EDIT 2: WSL and Docker are acting up again.

I am doing my best to quickly learn about and fix the things I don't know but the documentation is not as easy to navigate as I thought. There's not a great deal of detail in it despite the presentation being great.

As it stands I do not really know how I am going to go about parsing the response from logout, or whether SP initiated logout is even supported using SAMLIFY. What I wrote "works" but it also isn't being validated and I don't really know what I did. I know that I configured a POST binding for logout and that it manifests as a get request on the callback route but the way that I make the logout request and how the response comes back as a query param and then parsing it, I have a lot of work to do to figure out if that is the correct way of doing it and then how to do it.

I have taken to trying to also look through some of the test cases for inspiration but sometimes I feel like it just makes my head hurt more than it helps. This idea that the POST binding acts like a REDIRECT for logouts is already weird and reading stuff like this

in the docs makes me wonder if I am trying to do something that can't be done in the first place.

In any case there are clear next steps, clean up my code and land this signature-less, essentially validation-less SAML code because it works well enough to get logged in with the local IDP, then get the signature working on the assertions, unless it's the message that I am supposed to sign, not the assertions, because those are separate things and now I am unsure about that as well. Then figure out logout properly, also does logout have to be signed? Also, are the dependencies for the XML validator that I imported good?

I'm making a mess of things again, but that's not always bad, hence the title.

Failing Forward

I mean, I did add a saml server, a few callbacks and actually login and out through simple saml php idp from the docker container so that's something I guess.

Local IDP

sfrunza13 — Sun, 12 Feb 2023 19:29:34 +0000

As per issue 105 and PR 174, we have a docker container that will act as a local IDP with a few users it recognizes that it will return SAML response claims for.

Ctrl + C the foundation

For our purposes in Starchart we intend to use a SAML auth flow similar to how we had it in Telescope, we are using Remix and SAMLIFY instead of passport SAML however and this will prove to be a little different as I get into writing the SAML server next week, but there is a lot of cross over in what we will have to work with. For example in both cases we will have to have a local IDP that will provide us with a SAML response that contains all the claims that we expect to receive from Microsoft Active Directory in production (more or less). The configuration we have in Telescope is that of a docker container that exposes simpleSAMLphp on PORT 8081 upon which we can access the mock IDP and the xml metadata we need to be able to work with it. The following is an example of the format the metadata file takes:

<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="http://localhost:8081/simplesaml/saml2/idp/metadata.php">
  <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIDXTCCAkWgAwIBAgIJALmVVuDWu4NYMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTYxMjMxMTQzNDQ3WhcNNDgwNjI1MTQzNDQ3WjBFMQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzUCFozgNb1h1M0jzNRSCjhOBnR+uVbVpaWfXYIR+AhWDdEe5ryY+CgavOg8bfLybyzFdehlYdDRgkedEB/GjG8aJw06l0qF4jDOAw0kEygWCu2mcH7XOxRt+YAH3TVHa/Hu1W3WjzkobqqqLQ8gkKWWM27fOgAZ6GieaJBN6VBSMMcPey3HWLBmc+TYJmv1dbaO2jHhKh8pfKw0W12VM8P1PIO8gv4Phu/uuJYieBWKixBEyy0lHjyixYFCR12xdh4CA47q958ZRGnnDUGFVE1QhgRacJCOZ9bd5t9mr8KLaVBYTCJo5ERE8jymab5dPqe5qKfJsCZiqWglbjUo9twIDAQABo1AwTjAdBgNVHQ4EFgQUxpuwcs/CYQOyui+r1G+3KxBNhxkwHwYDVR0jBBgwFoAUxpuwcs/CYQOyui+r1G+3KxBNhxkwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEAAiWUKs/2x/viNCKi3Y6blEuCtAGhzOOZ9EjrvJ8+COH3Rag3tVBWrcBZ3/uhhPq5gy9lqw4OkvEws99/5jFsX1FJ6MKBgqfuy7yh5s1YfM0ANHYczMmYpZeAcQf2CGAaVfwTTfSlzNLsF2lW/ly7yapFzlYSJLGoVE+OHEu8g5SlNACUEfkXw+5Eghh+KzlIN7R6Q7r2ixWNFBC/jWf7NKUfJyX8qIG5md1YUeT6GBW9Bm2/1/RiO24JTaYlfLdKK9TYb8sG5B+OLab2DImG99CJ25RkAcSobWNF5zD0O6lgOo3cEdB/ksCq3hmtlC/DlLZ/D8CJ+7VuZnS1rR2naQ==</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:KeyDescriptor use="encryption">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIDXTCCAkWgAwIBAgIJALmVVuDWu4NYMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTYxMjMxMTQzNDQ3WhcNNDgwNjI1MTQzNDQ3WjBFMQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzUCFozgNb1h1M0jzNRSCjhOBnR+uVbVpaWfXYIR+AhWDdEe5ryY+CgavOg8bfLybyzFdehlYdDRgkedEB/GjG8aJw06l0qF4jDOAw0kEygWCu2mcH7XOxRt+YAH3TVHa/Hu1W3WjzkobqqqLQ8gkKWWM27fOgAZ6GieaJBN6VBSMMcPey3HWLBmc+TYJmv1dbaO2jHhKh8pfKw0W12VM8P1PIO8gv4Phu/uuJYieBWKixBEyy0lHjyixYFCR12xdh4CA47q958ZRGnnDUGFVE1QhgRacJCOZ9bd5t9mr8KLaVBYTCJo5ERE8jymab5dPqe5qKfJsCZiqWglbjUo9twIDAQABo1AwTjAdBgNVHQ4EFgQUxpuwcs/CYQOyui+r1G+3KxBNhxkwHwYDVR0jBBgwFoAUxpuwcs/CYQOyui+r1G+3KxBNhxkwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEAAiWUKs/2x/viNCKi3Y6blEuCtAGhzOOZ9EjrvJ8+COH3Rag3tVBWrcBZ3/uhhPq5gy9lqw4OkvEws99/5jFsX1FJ6MKBgqfuy7yh5s1YfM0ANHYczMmYpZeAcQf2CGAaVfwTTfSlzNLsF2lW/ly7yapFzlYSJLGoVE+OHEu8g5SlNACUEfkXw+5Eghh+KzlIN7R6Q7r2ixWNFBC/jWf7NKUfJyX8qIG5md1YUeT6GBW9Bm2/1/RiO24JTaYlfLdKK9TYb8sG5B+OLab2DImG99CJ25RkAcSobWNF5zD0O6lgOo3cEdB/ksCq3hmtlC/DlLZ/D8CJ+7VuZnS1rR2naQ==</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost:8081/simplesaml/saml2/idp/SingleLogoutService.php"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost:8081/simplesaml/saml2/idp/SSOService.php"/>
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

and all of this information is stood up for us on a url that we can pull it from http://localhost:8081/simplesaml/saml2/idp/metadata.php.

Next Steps

Now that we have a test IDP we can configure our starchart program to be an SP that works with bindings to it so that when we sign in it will redirect to the IDP and then once the user info is passed to the IDP it will return a SAML response with claims about the user that we can use as a service provider to allow them access to our application. This will be done through SAMLIFY, I am thinking that the IDP can be configured with something similar to the following except replacing the path with a path to the xml to our simpleSAMLphp IDP

const idp = saml.IdentityProvider({
  metadata: fs.readFileSync('./metadata/onelogin_metadata_486670.xml')
});

and we can configure Starchart as a service provider in code and generate the SP XML and then expose the metadata to the public as per the following docs: https://samlify.js.org/#/configuration. This is similar to what is done in Telescope under SSO in the Authentication and Saml-Metadata files.

Ensuing work from this week's PR

This week's PR lead to the creation of the following issue so that we can have a few existing users associated with the mock IDP users so that we can test existing users returning and one or two users in the IDP that we test as first time users of the application.

Also I have yet to add documentation on the Mock IDP and the users that we have configured for use currently.

The IDP itself is not really being used by starchart yet so I am debating doing the SSO flow to see it work first before documenting but there's no real reason I can't do both.

Remixing the Blues

sfrunza13 — Sun, 05 Feb 2023 20:38:30 +0000

Starting to contribute

This week on the starchart project we set out what we were going to commit to completing for the 0.1 Milestone. This is now concrete coding work we are talking about, along with continuously reading documentation and now also peer-reviewing PRs and helping one another get setup.

In the very beginning of the week I had some issues getting the starchart project running on my machine and the team got together on a call after our first scheduled meeting and helped me out. I learned that I had to build before running and that my mysql-data folder had some issues so it had to be deleted and the generated again.

I had problems again later, eventually after bouncing ideas back and forth with TD on how to solve it it turns out deleting my node modules and re installing worked (just npm installing without deleting did not). Still not sure why but in any case, I was able to work with Star Chart and I got to doing the small part that I had set out to.

Initial Auth

The issue I had commited to was to create a login button that would authenticate as the single user that is seeded into the dev database, I then also created a log out button that would destroy the session.

Initially I had thought that I would have to write the session.server.ts file and make my own createCookieSession methods to work with, docs for which can be found here. This did not turn out to be the case because apparently the blues stack already has a really great session.server.ts file with some really nice methods such as some require methods that will automatically throw redirects to login routes if conditions aren't met and things of that nature which I made use of.

There is also a longer example that takes you through the creation of a joke application that has helped me work with remix here.

The logic that I use comes from these docs.

What I did was I added 2 files login.tsx and logout.tsx under the routes folder. The login.tsx has an action that occurs upon the press of the login button that will use the prewritten createUserSession() method with the seeded users username and redirect to the Index page.

I then edited the index page to include a loader that would require the authenticated user, there was yet again a really helpful pre-written function to use from session.server.ts requireUsername() that checks the request from Loader Arguments for the username and if it does not find it it redirects to login. If it does find it it returns the user's username to the Index component to be able to make use of it when it renders the HTML.

I then added a button to the Index HTML that would use the action of the new logout route when pressed.

The logout route has the action I just mentioned which uses yet another pre-written function that is called logout() which destroys the session and it also has a loader just in case someone accidentally navigates to it. The loader simply redirects the client to the base Index route.

PRs and Reviews

Here are the 2 PRs that I made this week and the comments and changes associated with them.

The second one was a small one to change the user model and seed to match the changes to the Prisma Schema whereby name was split into first and last names.

I also did a few approvals on other students PRs. I really did not know how to improve them, they seemed good to me and that's what I wrote. I hate to not be able to contribute more but I also hate to see PRs that look really well done sitting there blocked with only one review.

Thanks for reading. Onto reading more about SAML.

Breaking Telescope

sfrunza13 — Mon, 30 Jan 2023 16:23:47 +0000

A 400 error

It all starts with an old 400 error that was occurring in Telescope for a while now, first documented here.

I had found that when we do the SAML sign in flow for authentication we seem to have, on occasion, a blocked session id cookie on the callback when the SAML response returns to us.

I could not reproduce this in the local setup, so I resolved to push tests for possible fixes to prod and David let me, which I am sure he regrets now.

This is the starting point for my experimentation and inevitable breaking of Telescope prod.

The first idea

This is my first PR and it outlines my first ideas.

Directly from the PR:

There is a 400 we sometimes get because the cookie that is sent to us with the post binding from Azure AD is sometimes blocked since it is from a different origin/site. Enabling sameSite 'none' should hopefully fix this. By default sameSite is set to 'Lax' which sometimes block incoming cookies from other sites such as the request AD makes to our callback.

This is all outlined nicely in the following document David found https://web.dev/samesite-cookie-recipes/#unsafe-requests-across-sites.

This pattern is used for sites that may redirect the user out to a remote service to perform some operation before returning, for example redirecting to a third-party identity provider. Before the user leaves the site, a cookie is set containing a single use token with the expectation that this token can be checked on the returning request to mitigate Cross Site Request Forgery (CSRF) attacks. If that returning request comes via POST then it will be necessary to mark the cookies as SameSite=None; Secure.

This took Telescope from sometimes not working and returning the 400 to ALWAYS not working and returning a 400. Luckily I am not out of ideas, but unfortunately none of them have worked since either...

Second idea

My second PR. Since in production Telescope express server is behind two proxies in Traefik and nginx I thought maybe using this trust setting with 2 hops would be enough to allow the requests to maintain their cookies even now that they were set as secure and sameSite none. This was not the case.

Example:

var app = express()
app.set('trust proxy', 1) // trust first proxy
app.use(session({
  secret: 'keyboard cat',
  resave: false,
  saveUninitialized: true,
  cookie: { secure: true }
}))

My final ideas

My final ideas before resetting prod that I have not yet tested are to change the origin to be explicit instead of a wildcard *. Because I have read that cors needs to be specified if the cookie is secure. I also want to try setting express.urlencoded({ extended: true }) to false in Satellite src because in all examples I have seen so far they have it set to false which uses a different query string library and the default setting of true has been deprecated as per the docs. The odds that that could actually be the problem is really low but it's worth a shot.

Problem now is that the explicit origin is different based on the environment Telescope is run in, and I have to find a way to dynamically change it based on where/how it's being run.

Hopefully in any case I will be able to finish my testing and have it running at least as well as it was before I messed with it.