ஒற்றை உள்நுழைவு¶

Canaille பல OAuth2 மற்றும் OpenID இணை specifications செயல்படுத்துகிறது, இது பயனர்கள் Canaille இல் தங்களை ஒருமுறை உள்நுழைய அனுமதிக்கிறது மற்றும் புதிதாக உள்நுழையாமல் பிற பயன்பாடுகளுக்கான அணுகலைப் பெறுகிறது.

நிறுவல்¶

ஒற்றை உள்நுழைவு அம்சத்தைப் பயன்படுத்த, oidc package கூடுதல் உடன் Canaille ஐ நிறுவ வேண்டும். பின்னர் நற்பொருத்தம் இயல்புநிலையாக இயக்கப்படும், ஆனால் ENABLE_OIDC உள்ளமைவு அளவுருவுடன் முடக்கலாம்.

கண்டுபிடிப்பு முனைப்புள்ளிகள்¶

OAuth2 கண்டுபிடிப்பு முடிவுப்புள்ளி /.well-known/oauth-authorization-server இல் அமைந்துள்ளது மற்றும் OpenID இணை கண்டுபிடிப்பு முடிவுப்புள்ளி /.well-known/openid-configuration இல் அமைந்துள்ளது.

These endpoints return a JSON discovery document that lists every other endpoint (authorization, token, userinfo, JWKS…) along with the server capabilities, so that compliant clients can configure themselves automatically from the issuer URL alone.

மாறும் கிளையன்ட் பதிவு¶

The easiest way to register a client is to let the client register itself.

By default, dynamic client registration requires a JWT registration token. Generate one with the canaille jwt registration command:

canaille jwt registration

Then pass this token to the registration endpoint as a bearer token:

curl \
   --request POST \
   --header "Authorization: Bearer $REGISTRATION_TOKEN" \
   --header "Content-Type: application/json" \
   --data '{"redirect_uris": ["https://client.example/callback"], "client_name": "Example client"}' \
   https://auth.example.test/oauth/register

The command generates a token with the client:register scope. Canaille must have a configured ACTIVE_JWKS and SERVER_NAME so the token can be signed and issued for the right server.

For test environments where authenticated registration is not needed, enable DYNAMIC_CLIENT_REGISTRATION_OPEN to allow clients to register without a token.

கைமுறை வாடிக்கையாளர் பதிவு¶

../_images/9c1dbd89f107234ba4873cd9569a6958.png — கிளையன்ட் கூட்டல் பக்கம்.¶

../_images/cb1aae34624585e6d9c3f21604399986.png — கிளையன்ட் கூட்டல் பக்கம்.¶

Users with the right MANAGE_OIDC permission can manage OIDC clients through the web interface.

கிளையன்ட் பதிப்பு மற்றும் பதிவு படிவத்தில் உள்ள புலங்கள் பற்றிய சில விவரங்கள் இங்கே உள்ளன:

பெயர்¶

இது இணைய இடைமுகத்திலும், குறிப்பாக ஒப்புதல் பக்கத்தில் காட்டப்படும் பெயராகும்.

தொடர்புகள்¶

வாடிக்கையாளருக்கு பொறுப்பான நபர்களின் மின்னஞ்சல் முகவரிகள் அவை.

யூரி¶

கிளையன்ட் பற்றிய தகவலை வழங்கும் வலைப்பக்கத்தின் முகவரி சரம்.

Note

This URL is used to determine the allowed origin for cross-origin requests (CORS) to OIDC and SCIM endpoints. This enables Single Page Applications to directly call these endpoints from the browser.

URIS ஐ திருப்பி விடுங்கள்¶

அங்கீகாரக் குறியீடு மற்றும் மறைமுகமான ஓட்டங்கள் போன்ற வழிமாற்று அடிப்படையிலான ஓட்டங்களில் பயன்படுத்துவதற்கான URIகள்.

இடுகையிடப்பட்ட யுஆர்ஐக்களைத் திருப்பி விடுங்கள்¶

கிளையன்ட் பயனர்களை வெளியேற்றிய பிறகு திருப்பி அனுப்பும் URIகள்.

வகைகளை வழங்கவும்¶

கிள்ளாக்கு இறுதிப் புள்ளியில் கிளையன்ட் பயன்படுத்தக்கூடிய வகைகளை வழங்கவும்.

கடவுச்சொல் வாடிக்கையாளர்கள் தங்கள் கடவுச்சொல்லை அங்கீகரிப்பு சேவையகத்திற்கு அனுப்புவதன் மூலம் பயனர்களை அங்கீகரிக்க அனுமதிக்கிறது. இது பாதுகாப்பற்ற ஓட்டமாகக் கருதப்படுகிறது மற்றும் உள்வரும் OAuth 2.1 விவரக்குறிப்பிலிருந்து அகற்றப்பட்டது. க்ளையன்ட் மற்ற பாதுகாப்பான ஓட்டத்தை ஆதரிக்காதபோது மட்டுமே இந்த மானியத்தை இயக்கவும்.
அங்கீகாரக் குறியீடு இறுதிப் பயனர்களை அங்கீகரிப்பு சேவையகத்திற்குத் திருப்பிவிடும், விருப்பமாக அவர்களின் ஒப்புதலைக் கேட்டு, பின்னர் பயனர்களை கிளையன்ட் பயன்பாட்டிற்கு அங்கீகரிப்புக் குறியீடு மூலம் திருப்பிவிடலாம், அதை இரண்டாவது முறையாக அணுகல் டோக்கன் மூலம் பரிமாறிக்கொள்ளலாம். இது மிகவும் பொதுவான மானிய வகை.
** மறைமுகமான** இறுதிப் பயனர்களை அங்கீகார சேவையகத்திற்குத் திருப்பிவிடும், விருப்பமாக அவர்களின் ஒப்புதலைக் கேட்கவும், பின்னர் பயனர்களை கிளையன்ட் பயன்பாட்டிற்கு அணுகல் டோக்கன் மூலம் திருப்பிவிடவும். இந்த மானிய வகையானது அங்கீகாரக் குறியீட்டை விட குறைவான பாதுகாப்பு கொண்டது, மேலும் இது SPA போன்ற அவர்களின் நற்சான்றிதழ்களின் ரகசியத்தன்மைக்கு பொறுப்பு அளிக்க முடியாத கிளையன்ட் பயன்பாடுகளுக்கு மட்டுமே பயன்படுத்தப்படும்.
ஐப்ரிட் என்பது மறைமுகமான மற்றும் அங்கீகாரக் குறியீடு ஆகியவற்றின் கலவையாகும், மேலும் மறைமுகமான பாதுகாப்பு இயல்புநிலைகளைப் பகிரவும்.
புதுப்பிப்பு டோக்கன் பாதுகாக்கப்பட்ட ஆதாரங்களை அணுக பயன்படுத்த முடியாத டோக்கனைக் கேட்கிறது, ஆனால் பயனர் கைமுறை தலையீடு இல்லாமல் புதிய அணுகல் கிள்ளாக்கைப் பெற பயன்படுத்தலாம். இது பொதுவாக பயனுள்ளதாக இருக்கும்.
கிளையண்ட் நற்சான்றிதழ்கள் என்பது பயனர் தொடர்பு எதிர்பார்க்காத போது, சர்வர்-டு-சர்வர் பயன்பாடுகளுக்குப் பயன்படுத்தப்படும். எடுத்துக்காட்டாக, இது :doc:`provisioning <provisioning>`க்கு பயன்படுத்தப்பட வேண்டிய மானிய வகையாகும்.
JWT தாங்கி அங்கீகரிக்கப்பட்ட சேவையகத்தால் கையொப்பமிடப்பட்ட JWT ஐ அணுகல் டோக்கனுக்கு எதிராக பரிமாறிக்கொள்ள வாடிக்கையாளர்களை அனுமதிக்கிறது.

நோக்கம்¶

Kinds of information the client can request about users. See Claims returned to applications for the available scopes and the claims each one provides.

மறுமொழி வகைகள்¶

கிளையன்ட் அங்கீகார முடிவுப் புள்ளியில் பயன்படுத்தக்கூடிய பதில் வகைகள்.

குறியீடு அங்கீகாரக் குறியீட்டில் பயன்படுத்தப்படுகிறது மேலும் ஐப்ரிட் அங்கீகார ஓட்டங்களில் பயன்படுத்தலாம்.
டோக்கன் மற்றும் ஐடி_டோக்கன் ஆகியவை ** மறைமுகமாக** பயன்படுத்தப்படுகின்றன, மேலும் ஐப்ரிட் அங்கீகார ஓட்டங்களில் பயன்படுத்தப்படலாம்.

கிள்ளாக்கு எண்ட்பாயிண்ட் அங்கீகார முறை¶

கிள்ளாக்கு இறுதிப் புள்ளியில் கிளையன்ட் பயன்படுத்தும் அங்கீகார முறை.

எதுவுமில்லை கிள்ளாக்கு எண்ட்பாயிண்டில் வாடிக்கையாளர்கள் அங்கீகரிக்கவில்லை என்பதைக் குறிக்கிறது. இது பாதுகாப்பற்றதாகக் கருதப்படுகிறது, மேலும் இது மறைமுகமான அங்கீகார ஓட்டத்திற்கு மட்டுமே பயன்படுத்தப்பட வேண்டும்.
client_secret_basic கோரிக்கை தலைப்புகளில் வாடிக்கையாளர்கள் தங்கள் நற்சான்றிதழ்களை அனுப்ப வேண்டும் என்று எதிர்பார்க்கிறது.
client_secret_post கோரிக்கையின் POST பேலோடில் வாடிக்கையாளர்கள் தங்கள் சான்றுகளை அனுப்ப வேண்டும் என்று எதிர்பார்க்கிறது.
private_key_jwt கோரிக்கை POST பேலோடில் கிளையன்ட் தனிப்பட்ட சமச்சீரற்ற விசைகளுடன் கையொப்பமிடப்பட்ட JWT ஐ கடந்து செல்கிறது. இது மிகவும் பாதுகாப்பானதாகக் கருதப்படுகிறது, மேலும் கிளையன்ட் அதன் பொது விசைகளை இணையத்தில் jwks_uri பண்புக்கூறுகளைப் பயன்படுத்தி வெளியிட்டால்.
client_secret_jwt வாங்கி secret பண்புக்கூறுடன் கையொப்பமிடப்பட்ட JWTஐ POST பேலோட் கோரிக்கையில் அனுப்புகிறது. private_key_jwt ஐ விடக் குறைவாக இருந்தாலும் இது பாதுகாப்பானதாகக் கருதப்படுகிறது, ஆனால் இதற்கு கிளையன்ட் அதன் சமச்சீரற்ற விசைகளை வெளியிட வேண்டியதில்லை, எனவே இதை அமைப்பது மிகவும் எளிதாக இருக்கும்.

பார்வையாளர்கள்¶

இந்த வாங்கி வெளியிடும் டோக்கன்களைப் பயன்படுத்த விரும்பும் பிற வாடிக்கையாளர்கள்.

லோகோ யூரி¶

இந்த கிளையண்டின் லோகோவுக்கான URL.

பணி விதிமுறைகள் யூரி¶

கிளையண்டின் பணி விதிமுறைகளுக்கான URL.

கொள்கை யூரி¶

கிளையண்டின் தனியுரிமைக் கொள்கைக்கான URL.

மென்பொருள் ஐடி¶

இந்த கிளையண்டிற்கான தனிப்பட்ட அடையாளங்காட்டி, அது சரியான நேரத்தில் நிலையானதாகவும் அனைத்து அடையாள வழங்குநர்களுக்கும் பொதுவானதாகவும் இருக்க வேண்டும்.

மென்பொருள் பதிப்பு¶

கிளையண்டின் பதிப்பு.

சாதொபொகு இணைய விசைகள்¶

கிளையண்டின் பொது சாதொபொகு இணைய விசைகள்.

சாதொபொகு இணைய விசைகள் யூரி¶

கிளையண்டின் பொது சாதொபொகு இணைய விசைகளை சுட்டிக்காட்டும் URI.

நம்பகமானவர்¶

வாடிக்கையாளர் ஒப்புதல் உரையாடல்களைக் காட்ட வேண்டுமா.

Configuring the client application¶

Once the client is registered, configure the application itself. Most OIDC clients only need three things:

the Issuer URL: your Canaille base URL (e.g. https://auth.example.org). Clients that support discovery fetch every endpoint from the Discovery endpoints automatically;
the Client ID and Client Secret obtained during registration;
the scopes the application should request (see Scope).

Applications that do not support discovery must be configured with each endpoint manually; you can read their values from the discovery document (see Discovery endpoints).

Claims returned to applications¶

The Scope requested by a client controls which claims Canaille returns in the ID token and at the userinfo endpoint. Request scopes explicitly: groups, address and phone are not included in profile.

நோக்கம்	Claims returned
`openid`	`sub` (always present, the user identifier)
`profile`	`name`, `given_name`, `family_name`, `preferred_username`, `picture`, `website`, `locale`, `updated_at`
`email`	`email`
`phone`	`phone_number`
`address`	`address` — a JSON object (`formatted`, `street_address`, `locality`, `region`, `postal_code`)
`groups`	`groups` — a JSON array of the user's group names. This scope is a Canaille extension, not part of the OpenID Connect core.

Mapping groups and roles¶

OpenID Connect does not standardize roles or groups, so this is usually the trickiest part of an integration.

Request the groups scope: Canaille then adds a groups claim to both the ID token and the userinfo response, containing the list of the user's group display names, for instance:

{
  "sub": "alice",
  "groups": ["admins", "staff"]
}

Map this claim to your application's roles or permissions. Every application does this differently (an attribute path, a role-mapping table, an allowed-groups list…): look for "OIDC group mapping" or "role mapping" in your application's documentation.

Customizing the claims¶

Claims are produced from Jinja templates, configurable in the UserInfoMappingSettings section (CANAILLE_OIDC.USERINFO_MAPPING). A user variable is available in each template.

If an application expects a claim under a different value, adapt the mapping. For example, to expose the email address as preferred_username instead of the display name:

[CANAILLE_OIDC.USERINFO_MAPPING]
PREFERRED_USERNAME = "{{ user.preferred_email }}"

Common integration pitfalls¶

Redirect URIs must match exactly. Scheme, host, port and path must be identical to what the application sends, including or excluding a trailing slash.
Prefer Authorization Code with PKCE. The supported code_challenge_methods are advertised in the discovery document (Discovery endpoints); use S256 when the client offers a choice.
Match the token endpoint authentication method. The method configured on the client (see Token endpoint authentication method) must match what the application sends. A mismatch is a frequent cause of invalid_client errors.
A nonce is required by default. Canaille enables REQUIRE_NONCE. If a client does not send a nonce, either fix the client or disable this option.
The issuer must match the public URL. Behind a reverse proxy, set SERVER_NAME and forward the appropriate headers, otherwise the issuer advertised in the discovery document (Discovery endpoints) and in the issued tokens will not match what clients expect. See வரிசைப்படுத்தல்.
The consent screen can be skipped for clients matching a TRUSTED_DOMAINS entry or marked Trusted.

சேவையக விசை மேலாண்மை¶

முக்கிய தலைமுறை¶

சாதொபொகு இணைய விசைகளை உருவாக்க canaille jwk create கட்டளையைப் பயன்படுத்தலாம். சேவையக விசையை நிறுவ, கட்டளையின் வெளியீட்டை ACTIVE_JWKS உள்ளமைவு அளவுருவில் வைக்கவும். OpenID இணை விவரக்குறிப்பு செயலில் உள்ள விசைகளில் குறைந்தது ஒரு RSA விசையையாவது வைத்திருக்க வேண்டும்.

முக்கிய சுழற்சி¶

அங்கீகார சேவையக விசைகளை ஒரு வழக்கமான அடிப்படையில் சுழற்றுவது ஒரு நல்ல நடைமுறையாக கருதப்படுகிறது.

விசை நிர்வாகத்திற்கான இரண்டு உள்ளமைவு அளவுருக்களைக் கொண்டுள்ளது: ACTIVE_JWKS மற்றும் INACTIVE_JWKS. டோக்கன்களில் கையொப்பமிட முந்தைய விசைகள் மட்டுமே பயன்படுத்தப்படுகின்றன, ஆனால் இரண்டிலும் பட்டியலிடப்பட்ட விசைகள் டோக்கன்களைச் சரிபார்க்கப் பயன்படுத்தப்படுகின்றன. இரண்டிலும் பட்டியலிடப்பட்டுள்ள விசைகள் சேவையக JWKS இறுதிப் புள்ளியில் காட்டப்படும், எனவே செயலற்ற விசைகள் மூலம் கையொப்பமிடப்பட்ட JWTகள் இன்னும் செல்லுபடியாகும் என்பதை வாடிக்கையாளர்கள் அறிந்து கொள்ளலாம்.

விசைகளைச் சுழற்ற, ACTIVE_JWKS இலிருந்து INACTIVE_JWKS க்கு ஒரு விசையை அனுப்பவும் மற்றும் Canaille ஐ மறுதொடக்கம் செய்யவும். சிறிது நேரம் கழித்து, நீங்கள் செயலற்ற விசைகளை அகற்றலாம்.