Wouldn't just using the
https://<KEYCLOAK-SERVER>/auth/realms/<REALM-NAME> a way to meet the
specification but also enable the multi-tenant behavior in Keycloak ?
Just an idea
On Fri, 31 Oct 2014 11:41:34 -0400
Bill Burke <bburke(a)redhat.com> wrote:
realm name by itself is a valid URL, its just not a url with a
scheme.
On 10/31/2014 8:41 AM, prab rrrr wrote:
> Read the spec once again and agree to your point that access code
> can only be used once. Regarding "iss", as long as realm name is
> replaced by URL, it should be good. I will do some more testing
> today, mostly on validating the signature of the token and will let
> you know if I find any discrepancies.
>
> Thanks once again, for the response and explanation.
>
>
> On Thursday, October 30, 2014 8:53 PM, Bill Burke
> <bburke(a)redhat.com> wrote:
>
>
> Section 3 does mention that the issuer is a URL using HTTPS, but
> this URL does not have to match the token endpoint URL. It is just
> a unique identifier for the issuer. That's it.
>
> Maybe I'm just not understanding OIDC, but what you are describing
> for "aud" and "azp" doesn't make sense to me. An ID Token
is not
> an access token. Its not something you pass around to use for
> authz. Neither do you pass around access codes. Access codes are
> only usable once.
>
> Keycloak just doesn't support multiple audiences. When an oauth
> client is registered, a set of valid redirect uri patterns are
> associated with it. You cannot associate a client with another
> client. The ID Token will only ever contain one client_id in the
> "aud" and the "azp" will always be blank because its an
optional
> setting.
>
> We support narrowed "trust" by role scope mappings. When an access
> token is created for a specific client, it is only granted
> permissions that are configured for that client's scope. For
> example:
>
> * Service 'A' has roles of "user" and "admin"
> * Service 'B' has roles of "admin" and "analyst"
> * User has a role mapping of A.user, A.admin, B.admin, B.analyst
> * Oauth client "C" is registered with a role scope mapping of A.user
> * Oauth client 'C' initiates a token request on behalf of the User,
> it gets an access token only with a permission of 'A.user' even
> though the user has other permissions. So it wouldn't be able to
> access Service 'B' at all.
>
>
>
> On 10/30/2014 6:42 PM, Raghuram wrote:
> > Hi Bill - here is my understanding of the spec:
> >
> > Section 3.1.3.7 of the core spec says that clients must validate
> > the
> id tokens. The third point of the same section says that "aud" can
> contain more than 1 element in which case the fourth point says
> that the client should verify that "azp" is present and the fifth
> point says azp should be verified against the client id
> >
> > Now when an oauth client registers, it can specify multiple
> > redirect
> Uris, corresponding to diff oauth clients that wish to participate
> in a single sign on. When a user tries to access first client and
> he is authenticated, the client just gets a code. If the code is
> passed to the second client ( the first client could be web app and
> the second client could be a database service) then the second
> client could get an Idtoken. The auth server (key cloak in this
> case) would then list all the client ids in "aud" and specify the
> second client in "azp" which will be validated by the second client.
> >
> > The above is a valid use case in our organization
> > ( authentication
> delegation). It gives flexibility to the apps ( especially sensitive
> ones) to pick the apps they trust rather than just participate in an
> organization wide single sign on.
> >
> > Section 3 (openID provider metadata) of the discovery spec
> > mentions
> that issuer is a url using https.
> >
> > Hope I make sense.
> >
> > Thanks.
> > Sent from my iPhone
> >
> >> On Oct 30, 2014, at 4:58 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
> >>
> >> Ivan, btw, looking at the library you are using, validation of
> >> the
> ID token is optional.
> >>
> >>> On 10/30/2014 4:15 PM, Raghuram wrote:
> >>> I tested with libraries based on Apache Oltu and even I noticed
> that realm name is being sent in the Idtoken under "iss". "aud"
is
> null when I included multiple redirect Uris which is breaking the
> validation (as per openid spec). "azp" is not being sent (it is
> optional unless more than 1 client is registered) - expect that to
> be sent once I register two clients.
> >> "aud" has been fixed in master.
> >>
> >> "iss" still is the realm name. This is just a unique
> >> identifier for
> the realm. And there is nothing in the spec that I could find that
> states that it must match the token endpoint URL. It just has to
> be a URL that uniquely identifies the issuer. It is something that
> is configured, or, found during OIDC discovery.
> >>
> >> "AZP
> >> Your interpretation of AZP is not my interpretation of AZP. #1.
> AZP is optional, we don't have to include it at all. #2 It would
> only have the value of the client that requested the token. In
> Keycloak, ID Tokens are generated and only given to one audience.
> >>
> >>
> >>> Used /account for userinfo end point that didn't work. Will
> >>> provide
> more feedback as I continue to test
> >>
> >> As I said before, we do not support userinfo yet. Our access
> >> tokens
> are Json Web Signatures signed by the realm and the content is an
> extended version of ID Tokens that contains additional keycloak
> metadata.
> >>
> >>> Fyi -My libraries were tested completely against a server
> implementation based on Mitre's open Id connect and they are good.
> >>
> >> It's on the roadmap to expand our OIDC support beyond the
> >> minimal
> requirements and to validate it against other implementations. Just
> haven't gotten to it yet.
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >>
http://bill.burkecentral.com <
http://bill.burkecentral.com/>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com <
http://bill.burkecentral.com/>
>
>