[Proposal/Discussion] New Credentials Issuers about oathkeeper HOT 7 CLOSED

I've got a headers issuer started at https://github.com/zikes/oathkeeper/tree/issuer-header/proxy with a passing test, however I still need to implement incoming header scrubbing and fill in more complex test cases. Let me know if you feel like that's on the right track.

from oathkeeper.

That's a pretty cool idea! I think you can build and cache templates so it shouldn't be too straining on performance. I think the Go template syntax needs getting used to but it's a pretty good place for it. I'd love to see a PR!

from oathkeeper.

@arekkas Some good news and bad news about the Go templating: the good news is that it turns out you can access maps via e.g. {{ .Extra.iss }} or {{ .Extra.aud }}. If the key doesn't exist in the map, it will fill in the zero value for the map value's type. The bad news is that the zero value for interface{} is considered unprintable by the text/template package, and it will always print <no value> in such cases even if missingkey=zero is set for the template.

Currently my fix for this is to use a lookup FuncMap function, turning the syntax into {{ lookup .Extra \"iss\" }}, which looks even worse than the original {{ .Extra[\"iss\"] }} in my opinion 😬

Would it be possible to change the Extra field of AuthenticationSession to a map[string]string? Alternatively I can pretty easily convert the map to a map[string]string within the Issuer with fmt.Sprintf, but I don't know what you have planned for that Extra field so I don't know how it would behave down the road.

from oathkeeper.

I went ahead and implemented the map conversion method, in favor of having a better interface to present to the users. If Extra is going to potentially contain more complex data we can figure out a better solution. You can have a look at the current implementation at https://github.com/zikes/oathkeeper/tree/issuer-header/proxy

from oathkeeper.

Extra can have arbitrary data, for OAuth 2.0 Access Tokens it's - for example - the metadata associated with the access token. Depending on the server this can be float64, int, string, bool or a nested structure. It should therefore not be map[string]string

from oathkeeper.

How about .String(key), .Int(key) ...?

from oathkeeper.

I think I've worked out a FuncMap function that keeps it fairly clean and simple: https://play.golang.org/p/SyzsYJnaepW

I was mostly worried about having to create a complex key lookup system that mimics what text/template does for nesting maps, but with this function I can fall back on text/template for the lookup and override how it prints that value. Oathkeeper can specify that the print FuncMap function is the "safe" way to access keys and should be used for all values.

from oathkeeper.