5:59 a.m.
Hello,
A couple of weeks ago I submitted a partial implementation of artifact-binding (only
AuthnRequests were handled) as a pull request, mostly to have some code review before I
proceeded (though I didn't get any feedback).
Now I have fully implemented the artifact binding part of SAML. How should I proceed:
1. Should I close the current pull request, and submit a new one with the full code,
2. Should I commit the code on the same fork as I'm currently doing a PR on? It
should be adding into the PR and I can update the description to say that it's the
full code.
Best regards,
Alistair
7:54 a.m.
On 11/6/18 6:59 AM, Doswald Alistair wrote:
Hello,
A couple of weeks ago I submitted a partial implementation of artifact-binding (only
AuthnRequests were handled) as a pull request, mostly to have some code review before I
proceeded (though I didn't get any feedback).
Now I have fully implemented the artifact binding part of SAML. How should I proceed:
I can't comment on handling the pull request but I do want to make sure
the "fully implemented" includes both generating and consuming SAML
metadata with the newly introduced artifact bindings as well as the
ability to specify the artifact binding in the SAML client page of the
realm (probably under fine grained SAML endpoints). I believe there are
multiple independent code locations that generate metadata (e.g. admin
rest API vs. client installation tab in the admin console) so we'll want
to make sure all code locations are updated. Historically we've had
problems getting consistent metadata.
--
John Dennis
3:48 a.m.
Hello,
The SAML client page has three new options for artifact binding: a slider to force
artifact binding (for example if the client doesn't specify HTTP-Artifact in its
authnrequest, but we still want artifact binding fort that client), and two new fields in
the Fine-grained SAML endpoint configuration: "Artifact binding URL" (for
sending the artifact message) and "Artifact Resolution Service" (for sending an
ArtifactResolve message).
Import will read the "ArtifactResolutionService" and
"AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" and fill the two
fields in the Fine-grained SAML endpoint configuration correctly.
For the metadata however, I see the problem. I have all the artifact-related metadata
correctly at
http://<host>:<port>/auth/realms/<realm>/protocol/saml/descriptor, but
not in any of the formats on the installation page. At first I thought that it was just a
problem on my part, but in fact only the POST endpoints are displayed in the
"installation" metadata: Redirect and SOAP endpoints that are at
http://<host>:<port>/auth/realms/<realm>/protocol/saml/descriptor are
not in the "installation" metadata (any variant). Is this a more general bug? I
am currently building from master.
Are there any other metadata sources aside from those two of which I am unaware? I'm
not very familiar with the admin REST API, but looking at the overview in the
documentation, I didn't find any other obvious way to get SAML metadata.
Best regards,
Alistair
-----Original Message-----
From: John Dennis <jdennis(a)redhat.com>
Sent: mardi 6 novembre 2018 14:54
To: Doswald Alistair <alistair.doswald(a)elca.ch>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>; Hynek Mlnarik <hmlnarik(a)redhat.com>
Subject: Re: [keycloak-dev] Full implementation of SAML artifact-binding for [JIRA
KEYCLOAK-831]
On 11/6/18 6:59 AM, Doswald Alistair wrote:
Hello,
A couple of weeks ago I submitted a partial implementation of artifact-binding (only
AuthnRequests were handled) as a pull request, mostly to have some code review before I
proceeded (though I didn't get any feedback).
Now I have fully implemented the artifact binding part of SAML. How should I proceed:
I can't comment on handling the pull request but I do want to make sure the
"fully implemented" includes both generating and consuming SAML metadata with
the newly introduced artifact bindings as well as the ability to specify the artifact
binding in the SAML client page of the realm (probably under fine grained SAML endpoints).
I believe there are multiple independent code locations that generate metadata (e.g. admin
rest API vs. client installation tab in the admin console) so we'll want to make sure
all code locations are updated. Historically we've had problems getting consistent
metadata.
--
John Dennis
7:28 a.m.
On 11/7/18 4:48 AM, Doswald Alistair wrote:
Hello,
The SAML client page has three new options for artifact binding: a
slider to force artifact binding (for example if the client doesn't
specify HTTP-Artifact in its authnrequest, but we still want artifact
binding fort that client), and two new fields in the Fine-grained
SAML endpoint configuration: "Artifact binding URL" (for sending the
artifact message) and "Artifact Resolution Service" (for sending an
ArtifactResolve message).
Import will read the "ArtifactResolutionService" and
"AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" and fill
the two fields in the Fine-grained SAML endpoint configuration
correctly.
Thank you, that sounds great.
For the metadata however, I see the problem. I have all the
artifact-related metadata correctly at
http://<host>:<port>/auth/realms/<realm>/protocol/saml/descriptor,
but not in any of the formats on the installation page. At first I
thought that it was just a problem on my part, but in fact only the
POST endpoints are displayed in the "installation" metadata: Redirect
and SOAP endpoints that are at
http://<host>:<port>/auth/realms/<realm>/protocol/saml/descriptor are
not in the "installation" metadata (any variant). Is this a more
general bug? I am currently building from master.
Are there any other metadata sources aside from those two of which I
am unaware? I'm not very familiar with the admin REST API, but
looking at the overview in the documentation, I didn't find any
other obvious way to get SAML metadata.
The /auth/realms/<realm>/protocol/saml/descriptor REST API and the
client installation tab in the admin console are the only two I'm aware
of. But I'm not a Keycloak dev so I can't say for sure if any others
might be lurking. Several years ago I looked at the source code for
generating metadata and REST endpoint and the client installation tab
used two different implementations instead of common code as I recall.
Best regards,
Alistair
-----Original Message----- From: John Dennis <jdennis(a)redhat.com>
Sent: mardi 6 novembre 2018 14:54 To: Doswald Alistair
<alistair.doswald(a)elca.ch>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>; Hynek Mlnarik <hmlnarik(a)redhat.com>
Subject: Re: [keycloak-dev] Full implementation of SAML
artifact-binding for [JIRA KEYCLOAK-831]
On 11/6/18 6:59 AM, Doswald Alistair wrote:
> Hello,
>
> A couple of weeks ago I submitted a partial implementation of
> artifact-binding (only AuthnRequests were handled) as a pull
> request, mostly to have some code review before I proceeded
> (though I didn't get any feedback).
>
> Now I have fully implemented the artifact binding part of SAML. How
> should I proceed:
I can't comment on handling the pull request but I do want to make
sure the "fully implemented" includes both generating and consuming
SAML metadata with the newly introduced artifact bindings as well as
the ability to specify the artifact binding in the SAML client page
of the realm (probably under fine grained SAML endpoints). I believe
there are multiple independent code locations that generate metadata
(e.g. admin rest API vs. client installation tab in the admin
console) so we'll want to make sure all code locations are updated.
Historically we've had problems getting consistent metadata.
-- John Dennis
--
John Dennis
2243
days inactive
2244
days old
3 comments
2 participants
participants (2)
-
Doswald Alistair -
John Dennis