SAML Implementation in Kratos

.docker/Dockerfile-alpine

@@ -1,4 +1,4 @@
-FROM alpine:3.15.4
+FROM alpine:3.16
 
 # Because this image supports SQLite, we create /home/ory and /home/ory/sqlite which is owned by the ory user
 # and declare /home/ory/sqlite a volume.
@@ -10,7 +10,7 @@ FROM alpine:3.15.4
 RUN addgroup -S ory; \
     adduser -S ory -G ory -D -u 10000 -h /home/ory -s /bin/nologin; \
     chown -R ory:ory /home/ory
-RUN apk --no-cache --update-cache --upgrade --latest add ca-certificates
+RUN apk --update upgrade && apk --no-cache --update-cache --upgrade --latest add ca-certificates
 
 WORKDIR /home/ory
 

.docker/Dockerfile-build

@@ -1,13 +1,14 @@
 # syntax = docker/dockerfile:1-experimental
-FROM golang:1.18-alpine3.15 AS base
+FROM golang:1.19-alpine3.16 AS base
 
-RUN apk --no-cache --update-cache --upgrade --latest add build-base git gcc bash
+RUN apk --update upgrade && apk --no-cache --update-cache --upgrade --latest add ca-certificates build-base gcc
 
 WORKDIR /go/src/github.com/ory/kratos
 
 ADD go.mod go.mod
 ADD go.sum go.sum
 ADD internal/httpclient/go.* internal/httpclient/
+ADD internal/client-go/go.* internal/client-go/
 
 ENV GO111MODULE on
 ENV CGO_ENABLED 1
@@ -25,7 +26,7 @@ RUN --mount=type=cache,target=/root/.cache/go-build go build -tags sqlite \
     -ldflags="-X 'github.com/ory/kratos/driver/config.Version=${VERSION}' -X 'github.com/ory/kratos/driver/config.Date=${BUILD_DATE}' -X 'github.com/ory/kratos/driver/config.Commit=${COMMIT}'" \
     -o /usr/bin/kratos
 
-FROM alpine:3.15.4
+FROM alpine:3.16
 
 RUN addgroup -S ory; \
     adduser -S ory -G ory -D -u 10000 -h /home/ory -s /bin/nologin; \

.docker/Dockerfile-debug

@@ -1,8 +1,8 @@
-FROM golang:1.18-buster
+FROM golang:1.19-buster
 ENV CGO_ENABLED 1
 
 RUN apt-get update && apt-get install -y --no-install-recommends inotify-tools psmisc
-RUN go get github.com/go-delve/delve/cmd/dlv
+RUN go install github.com/go-delve/delve/cmd/dlv@latest
 
 COPY script/debug-entrypoint.sh /entrypoint.sh
 

.github/FUNDING.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/FUNDING.yml
+
 # These are supported funding model platforms
 
 # github:

.github/ISSUE_TEMPLATE/BUG-REPORT.yml

@@ -1,17 +1,20 @@
-description: 'Create a bug report'
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/BUG-REPORT.yml
+
+description: "Create a bug report"
 labels:
   - bug
-name: 'Bug Report'
+name: "Bug Report"
 body:
   - attributes:
       value: "Thank you for taking the time to fill out this bug report!\n"
     type: markdown
   - attributes:
-      label: 'Preflight checklist'
+      label: "Preflight checklist"
       options:
         - label:
-            'I could not find a solution in the existing issues, docs, nor
-            discussions.'
+            "I could not find a solution in the existing issues, docs, nor
+            discussions."
           required: true
         - label:
             "I agree to follow this project's [Code of
@@ -22,18 +25,18 @@ body:
             Guidelines](https://github.com/ory/kratos/blob/master/CONTRIBUTING.md)."
           required: true
         - label:
-            'This issue affects my [Ory Cloud](https://www.ory.sh/) project.'
+            "This issue affects my [Ory Network](https://www.ory.sh/) project."
         - label:
-            'I have joined the [Ory Community Slack](https://slack.ory.sh).'
+            "I have joined the [Ory Community Slack](https://slack.ory.sh)."
         - label:
-            'I am signed up to the [Ory Security Patch
-            Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53).'
+            "I am signed up to the [Ory Security Patch
+            Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53)."
     id: checklist
     type: checkboxes
   - attributes:
-      description: 'A clear and concise description of what the bug is.'
-      label: 'Describe the bug'
-      placeholder: 'Tell us what you see!'
+      description: "A clear and concise description of what the bug is."
+      label: "Describe the bug"
+      placeholder: "Tell us what you see!"
     id: describe-bug
     type: textarea
     validations:
@@ -47,28 +50,28 @@ body:
         1. Run `docker run ....`
         2. Make API Request to with `curl ...`
         3. Request fails with response: `{"some": "error"}`
-      label: 'Reproducing the bug'
+      label: "Reproducing the bug"
     id: reproduce-bug
     type: textarea
     validations:
       required: true
   - attributes:
       description:
-        'Please copy and paste any relevant log output. This will be
+        "Please copy and paste any relevant log output. This will be
         automatically formatted into code, so no need for backticks. Please
-        redact any sensitive information'
-      label: 'Relevant log output'
+        redact any sensitive information"
+      label: "Relevant log output"
       render: shell
       placeholder: |
         log=error ....
     id: logs
     type: textarea
   - attributes:
       description:
-        'Please copy and paste any relevant configuration. This will be
+        "Please copy and paste any relevant configuration. This will be
         automatically formatted into code, so no need for backticks. Please
-        redact any sensitive information!'
-      label: 'Relevant configuration'
+        redact any sensitive information!"
+      label: "Relevant configuration"
       render: yml
       placeholder: |
         server:
@@ -77,16 +80,16 @@ body:
     id: config
     type: textarea
   - attributes:
-      description: 'What version of our software are you running?'
+      description: "What version of our software are you running?"
       label: Version
     id: version
     type: input
     validations:
       required: true
   - attributes:
-      label: 'On which operating system are you observing this issue?'
+      label: "On which operating system are you observing this issue?"
       options:
-        - Ory Cloud
+        - Ory Network
         - macOS
         - Linux
         - Windows
@@ -95,19 +98,19 @@ body:
     id: operating-system
     type: dropdown
   - attributes:
-      label: 'In which environment are you deploying?'
+      label: "In which environment are you deploying?"
       options:
-        - Ory Cloud
+        - Ory Network
         - Docker
-        - 'Docker Compose'
-        - 'Kubernetes with Helm'
+        - "Docker Compose"
+        - "Kubernetes with Helm"
         - Kubernetes
         - Binary
         - Other
     id: deployment
     type: dropdown
   - attributes:
-      description: 'Add any other context about the problem here.'
+      description: "Add any other context about the problem here."
       label: Additional Context
     id: additional
     type: textarea

.github/ISSUE_TEMPLATE/DESIGN-DOC.yml

@@ -1,8 +1,11 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml
+
 description:
-  'A design document is needed for non-trivial changes to the code base.'
+  "A design document is needed for non-trivial changes to the code base."
 labels:
   - rfc
-name: 'Design Document'
+name: "Design Document"
 body:
   - attributes:
       value: |
@@ -13,16 +16,16 @@ body:
         Ory is leaning heavily on [Google's design docs process](https://www.industrialempathy.com/posts/design-docs-at-google/)
         and [Golang Proposals](https://github.com/golang/proposal).
 
-        Writing a design doc prior to contributing your change ensures that your ideas are checked with
-        the community and maintainers. It will save you a lot of time developing things which might need changed
+        Writing a design doc before contributing your change ensures that your ideas are checked with
+        the community and maintainers. It will save you a lot of time developing things that might need to be changed
         after code reviews, and your pull requests will be merged faster.
     type: markdown
   - attributes:
-      label: 'Preflight checklist'
+      label: "Preflight checklist"
       options:
         - label:
-            'I could not find a solution in the existing issues, docs, nor
-            discussions.'
+            "I could not find a solution in the existing issues, docs, nor
+            discussions."
           required: true
         - label:
             "I agree to follow this project's [Code of
@@ -33,18 +36,18 @@ body:
             Guidelines](https://github.com/ory/kratos/blob/master/CONTRIBUTING.md)."
           required: true
         - label:
-            'This issue affects my [Ory Cloud](https://www.ory.sh/) project.'
+            "This issue affects my [Ory Network](https://www.ory.sh/) project."
         - label:
-            'I have joined the [Ory Community Slack](https://slack.ory.sh).'
+            "I have joined the [Ory Community Slack](https://slack.ory.sh)."
         - label:
-            'I am signed up to the [Ory Security Patch
-            Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53).'
+            "I am signed up to the [Ory Security Patch
+            Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53)."
     id: checklist
     type: checkboxes
   - attributes:
       description: |
         This section gives the reader a very rough overview of the landscape in which the new system is being built and what is actually being built. This isn’t a requirements doc. Keep it succinct! The goal is that readers are brought up to speed but some previous knowledge can be assumed and detailed info can be linked to. This section should be entirely focused on objective background facts.
-      label: 'Context and scope'
+      label: "Context and scope"
     id: scope
     type: textarea
     validations:
@@ -53,7 +56,7 @@ body:
   - attributes:
       description: |
         A short list of bullet points of what the goals of the system are, and, sometimes more importantly, what non-goals are. Note, that non-goals aren’t negated goals like “The system shouldn’t crash”, but rather things that could reasonably be goals, but are explicitly chosen not to be goals. A good example would be “ACID compliance”; when designing a database, you’d certainly want to know whether that is a goal or non-goal. And if it is a non-goal you might still select a solution that provides it, if it doesn’t introduce trade-offs that prevent achieving the goals.
-      label: 'Goals and non-goals'
+      label: "Goals and non-goals"
     id: goals
     type: textarea
     validations:
@@ -64,31 +67,31 @@ body:
         This section should start with an overview and then go into details.
         The design doc is the place to write down the trade-offs you made in designing your software. Focus on those trade-offs to produce a useful document with long-term value. That is, given the context (facts), goals and non-goals (requirements), the design doc is the place to suggest solutions and show why a particular solution best satisfies those goals.
 
-        The point of writing a document over a more formal medium is to provide the flexibility to express the problem set at hand in an appropriate manner. Because of this, there is no explicit guidance for how to actually describe the design.
-      label: 'The design'
+        The point of writing a document over a more formal medium is to provide the flexibility to express the problem at hand in an appropriate manner. Because of this, there is no explicit guidance on how to actually describe the design.
+      label: "The design"
     id: design
     type: textarea
     validations:
       required: true
 
   - attributes:
       description: |
-        If the system under design exposes an API, then sketching out that API is usually a good idea. In most cases, however, one should withstand the temptation to copy-paste formal interface or data definitions into the doc as these are often verbose, contain unnecessary detail and quickly get out of date. Instead focus on the parts that are relevant to the design and its trade-offs.
-      label: 'APIs'
+        If the system under design exposes an API, then sketching out that API is usually a good idea. In most cases, however, one should withstand the temptation to copy-paste formal interface or data definitions into the doc as these are often verbose, contain unnecessary detail and quickly get out of date. Instead, focus on the parts that are relevant to the design and its trade-offs.
+      label: "APIs"
     id: apis
     type: textarea
 
   - attributes:
       description: |
-        Systems that store data should likely discuss how and in what rough form this happens. Similar to the advice on APIs, and for the same reasons, copy-pasting complete schema definitions should be avoided. Instead focus on the parts that are relevant to the design and its trade-offs.
-      label: 'Data storage'
+        Systems that store data should likely discuss how and in what rough form this happens. Similar to the advice on APIs, and for the same reasons, copy-pasting complete schema definitions should be avoided. Instead, focus on the parts that are relevant to the design and its trade-offs.
+      label: "Data storage"
     id: persistence
     type: textarea
 
   - attributes:
       description: |
-        Design docs should rarely contain code, or pseudo-code except in situations where novel algorithms are described. As appropriate, link to prototypes that show the implementability of the design.
-      label: 'Code and pseudo-code'
+        Design docs should rarely contain code, or pseudo-code except in situations where novel algorithms are described. As appropriate, link to prototypes that show the feasibility of the design.
+      label: "Code and pseudo-code"
     id: pseudocode
     type: textarea
 
@@ -98,18 +101,18 @@ body:
 
         On one end of the extreme is the “greenfield software project”, where all we know are the goals, and the solution can be whatever makes the most sense. Such a document may be wide-ranging, but it also needs to quickly define a set of rules that allow zooming in on a manageable set of solutions.
 
-        On the other end are systems where the possible solutions are very well defined, but it isn’t at all obvious how they could even be combined to achieve the goals. This may be a legacy system that is difficult to change and wasn’t designed to do what you want it to do or a library design that needs to operate within the constraints of the host programming language.
+        On the other end are systems where the possible solutions are very well defined, but it isn't at all obvious how they could even be combined to achieve the goals. This may be a legacy system that is difficult to change and wasn't designed to do what you want it to do or a library design that needs to operate within the constraints of the host programming language.
 
-        In this situation you may be able to enumerate all the things you can do relatively easily, but you need to creatively put those things together to achieve the goals. There may be multiple solutions, and none of them are really great, and hence such a document should focus on selecting the best way given all identified trade-offs.
-      label: 'Degree of constraint'
+        In this situation, you may be able to enumerate all the things you can do relatively easily, but you need to creatively put those things together to achieve the goals. There may be multiple solutions, and none of them are great, and hence such a document should focus on selecting the best way given all identified trade-offs.
+      label: "Degree of constraint"
     id: constrait
     type: textarea
 
   - attributes:
       description: |
         This section lists alternative designs that would have reasonably achieved similar outcomes. The focus should be on the trade-offs that each respective design makes and how those trade-offs led to the decision to select the design that is the primary topic of the document.
 
-        While it is fine to be succinct about solution that ended up not being selected, this section is one of the most important ones as it shows very explicitly why the selected solution is the best given the project goals and how other solutions, that the reader may be wondering about, introduce trade-offs that are less desirable given the goals.
+        While it is fine to be succinct about a solution that ended up not being selected, this section is one of the most important ones as it shows very explicitly why the selected solution is the best given the project goals and how other solutions, that the reader may be wondering about, introduce trade-offs that are less desirable given the goals.
 
       label: Alternatives considered
     id: alternatives