No, if self-registration is disabled, a user cannot create an SSO connection on their identity by themselves. The creation of SSO connections is typically handled by an administrator or through the API. For instance, in Ory, SSO connections are part of the project configuration and can be managed through the Ory Console or the API. The API provides endpoints for creating, listing, and deleting SSO connections. Here is an example of how to create an SSO connection using the API:

bash curl -X PATCH --location "<https://api.console.ory.sh/projects/{{project_id}}>" \        -H "Authorization: Bearer ory_wak_..." \        -H "Content-Type: application/json" \        -d '[              {                "op": "add",                "path": "/services/identity/config/selfservice/methods/oidc/config/providers/-",                "value": {                  "client_id": "...",                  "client_secret": "...",                  "id": "ory-GPx1yPH4",                  "issuer_url": "<https://example.org>",                  "label": "My OIDC provider",                  "mapper_url": "<base64://ZnVuY3Rpb24oY3R4KSBjdHg>=",                  "organization_id": "6bb1c7d1-3b3e-4995-9e09-35649dc45a2b",                  "provider": "generic",                  "scope": ["openid", "offline_access", "email"]                }              }            ]' \      | jq ".project.services.identity.config.selfservice.methods.oidc.config.providers"

Please note that the

client_id

and

client_secret

are the credentials of the OIDC provider, and the

organization_id

is the ID of the organization to which the connection belongs. For more information, you can refer to the [Ory documentation](https://www.ory.sh/docs/kratos/organizations#create-an-sso-connections).

Based on the provided knowledge sources, there isn't a direct way to set up the SSO info on a user's identity when they log in. The SSO connections are typically configured at the organization level, not at the individual user level. When you create an SSO connection for an organization, all members of that organization must use one of the organization's OIDC SSO connections to log in. If a user's email domain matches that of the organization, they will see a "Sign in with SSO" button instead of the password field on the registration page. Here is an example of how to create an SSO connection for an organization:

bash curl -X PATCH --location "<https://api.console.ory.sh/projects/{{project_id}}>" \        -H "Authorization: Bearer ory_wak_..." \        -H "Content-Type: application/json" \        -d '[              {                "op": "add",                "path": "/services/identity/config/selfservice/methods/oidc/config/providers/-",                "value": {                  "client_id": "...",                  "client_secret": "...",                  "id": "ory-GPx1yPH4",                  "issuer_url": "<https://example.org>",                  "label": "My OIDC provider",                  "mapper_url": "<base64://ZnVuY3Rpb24oY3R4KSBjdHg>=",                  "organization_id": "6bb1c7d1-3b3e-4995-9e09-35649dc45a2b",                  "provider": "generic",                  "scope": ["openid", "offline_access", "email"]                }              }            ]' \      | jq ".project.services.identity.config.selfservice.methods.oidc.config.providers"

For more information, you can refer to the [Ory documentation](https://www.ory.sh/docs/kratos/organizations#create-an-sso-connections).

Based on the provided knowledge sources, there isn't a direct way to set up the SSO info on a user's identity when they log in programmatically. The SSO connections are typically configured at the organization level, not at the individual user level. When you create an identity programmatically, you can set its traits and schema, but the SSO information (like the

subject

in the

oidc

credentials) is not directly settable during this process. This information is typically obtained and managed during the SSO login flow. Here is an example of how to create an identity programmatically:

bash curl --request POST -sL \     --header "Authorization: Bearer ory_pat_xRKLsFEOUFQFVBjd6o3FQDifaLYhabGd" \     --header "Content-Type: application/json" \     --data '{     "schema_id": "<preset://email>",     "traits": {       "email": "[[email protected]](<https://www.ory.sh/cdn-cgi/l/email-protection>)"     }   }' <https://playground.projects.oryapis.com/admin/identities>

The server response contains the created identity:

json {     "id": "e01b5f2f-6afc-4194-8578-4cebcf69a4d5",     "schema_id": "<preset://email>",     "schema_url": "<https://playground.projects.oryapis.com/schemas/cHJlc2V0Oi8vZW1haWw>",     "state": "active",     "state_changed_at": "2022-02-24T13:38:05.27510048Z",     "traits": {       "email": "[[email protected]](<https://www.ory.sh/cdn-cgi/l/email-protection>)"     },     ... }

For more information, you can refer to the [Ory documentation](https://www.ory.sh/docs/kratos/manage-identities/create-users-identities).

Based on the provided knowledge sources, the data mapping feature in Ory is used to map the data returned by the sign-in provider to traits as defined in the identity schema. It doesn't directly mention the ability to map the

subject

into

credentials.oidc.config.providers.subject

. Here is an example of how data mapping is used in Ory:

json local claims = {     email_verified: false,   } + std.extVar('claims');      {     identity: {       traits: {         // Allowing unverified email addresses enables account         // enumeration attacks, especially if the value is used for         // e.g. verification or as a password login identifier.         //         // Therefore we only return the email if it (a) exists and (b) is marked verified         // by GitHub.         [if 'email' in claims && claims.email_verified then 'email' else null]: claims.email,       },     },   }

In this example, the

email

claim is mapped to the

traits.email

field in the identity schema. For more information, you can refer to the [Ory documentation](https://www.ory.sh/docs/kratos/social-signin/github#data-mapping).