shishi_tkt_tra...olicy_checked_p(3)

✨ shishi_tkt_transited_policy_checked_p(3) ✨

okay bestie, welcome to the shishi corner of the man pages 💖 this one lives in the shishi manual (section 3, library functions, iykyk), and it's a little function with a big name that's all about trusting your KDCs. let's get into it 🫶

---

🌸 NAME 🌸

shishi_tkt_transited_policy_checked_p — an API function, fr fr

---

🎀 SYNOPSIS 🎀

#include <shishi.h>

int shishi_tkt_transited_policy_checked_p(Shishi_tkt * tkt);

---

💅 ARGUMENTS 💅

• Shishi_tkt * tkt — input variable with ticket info. that's the whole vibe, she just wants the ticket 🎟️

---

🦋 DESCRIPTION 🦋

So the question on the table: determine if ticket has been policy checked for transit. Basically — did somebody already do the transited-field homework, or is this ticket still sus? 😭

Here's the lore, bestie. The application server is ultimately responsible for accepting or rejecting authentication, and it SHOULD check that only suitably trusted KDCs are relied upon to authenticate a principal. Like, don't just trust any random realm that rolls up to the function, okay?

The transited field in the ticket identifies which realms (and thus which KDCs) were involved in the authentication process, and an application server would normally check this field. If any of these are untrusted to authenticate the indicated client principal (probably determined by a realm-based policy), the authentication attempt MUST be rejected. And here's the part that catches people slipping: the presence of trusted KDCs in this list does not provide any guarantee; an untrusted KDC may have fabricated the list. 💀 not a vibe. don't let a fake list gaslight you.

Now, while the end server ultimately decides whether authentication is valid, the KDC for the end server's realm MAY apply a realm specific policy for validating the transited field and accepting credentials for cross-realm authentication. When the KDC applies such checks and accepts such cross-realm authentication, it will set the TRANSITED-POLICY-CHECKED flag in the service tickets it issues based on the cross-realm TGT. 👑

And a client MAY request that the KDCs not check the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are encouraged but not required to honor this flag — so like, it's a request, not a demand, and the KDC might just ignore you 🙈

🚨 Application servers MUST either do the transited-realm checks themselves, or reject cross-realm tickets without TRANSITED-POLICY-CHECKED set. That's a MUST, bestie. no skipping. no shortcuts. periodt.

---

🌈 RETURN VALUE 🌈

Returns non-0 iff the transited-policy-checked flag is set in the ticket. so like, truthy = the flag is there, 0 = she's not 💜

---

😭 REPORTING BUGS 😭

Found a bug? Report bugs to <bug-shishi@gnu.org>.

GNU Shishi home page: http://www.gnu.org/software/shishi/

General help using GNU software: http://www.gnu.org/gethelp/

---

👑 COPYRIGHT 👑

Copyright © 2002-2022 Simon Josefsson.

Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. 💖 (yes this is genuinely the license text, it's giving generous and we love that for it)

---

⭐ SEE ALSO ⭐

The full documentation for shishi is maintained as a Texinfo manual. If the info and shishi programs are properly installed at your site, the command

info shishi

should give you access to the complete manual. go read it, it's the main character energy of docs 📖✨

---

k that's the whole page!! this was shishi 1.0.3, the shishi_tkt_transited_policy_checked_p(3) era, and we ate 🍓💅 mwah, go check your transited fields bestie 🧚💜