search

davidben / webathena

An experiment to bring Kerberos and Project Athena to the web
MIT License
29 stars 10 forks source link

Cross-realm support #4

Open davidben opened 12 years ago

davidben commented 12 years ago

Figure out exactly what this entails. Certainly we'll need to handle some indirections when getting a cross-realm service ticket. We may also need something akin to registerProtocolHandler or Web Intents or just pasting URLs (eww) around to solve the "which OpenID provider do you want to login with" problem.

asedeno commented 3 years ago

Any more thoughts on this?

davidben commented 3 years ago

I don't remember much of what I was thinking about here or even how cross-realm works. I think it might have involved each realm having its own webathena install and some kind of federated scheme here.

This may not actually make any sense or be necessary. :-)

asedeno commented 3 years ago

So there are two different aspects of cross-realm that need to be taken into consideration:

  1. Supporting principals from multiple realms using webathena to access resources in their own realm.
  2. Supporting requesting a cross-realm service ticket.

For (1) I think limiting it to a configured realm is fine for now, and later we may want to support an allowed list of realms. For (2) the webathena kdc proxy needs to be flexible about which KDCs it talks to depending on the request, and then the client-side needs to not reject such requests out of hand.

davidben commented 3 years ago

Ah hrm that sounds familiar. For (2), I guess the client would need to implement whatever the client does to get a cross-realm service ticket (IIRC, it involved a few extra requests?), and then the proxy probably needs an allowlist? I suspect I limited what it talked to to avoid breaking an 18.x.x.x ACL or localhost-only service.

Looking at 8e39a16303dc423b51109810ddec02a9753885e6, it seems there was another concern that, if the proxy talks to something that's not actually a KDC, it'll timeout and the Python blocking CGI script style of web servers would get a bit upset here. It should be possible to be smarter here, but it may not be compatible with scripts.mit.edu.

asedeno commented 3 years ago

Broad strokes, ask our kdc for a krbtgt/OTHER-REALM@MY-REALM and use that to get service/ticket@OTHER-REALM from the other kdc. It might be worthwhile getting #6 done in the process.