8:23 a.m.
Shibboleth only supports transient name ids? I find that hard to
believe. Remember Keycloak would just look like any other client. IMO
you should go that route.
Also though, I think you might be able to write a Broker Mapper, take a
look at UsernameTemplateMapper. This SPI is undocumented and
unsupported at the moment, but I hope to change that soon.
On 1/14/2016 6:20 AM, Jérôme Blanchard wrote:
Hi all,
According to shibboleth specification, IdP of a federation usually use
transient NameID which makes Shibboleth impossible to interface with
keycloak, even if we manage the Discovery Service externally in order
to maintain IdP list mapping between federation and keycloak.
It's really annoying for me and I'm trying to investigate a way to
solve this problem.
In my federation, some doc say that if you need to manage personnal
user information in your application, you have to rely on a dedicated
attribute in order to retreive real user id and not the transient
opaque one. In this case, an attribute called eduPersoneTargetedId
exists and can be use by shibboleth.
I am trying to patch the saml broker in order to take into
consideration this attribute in a kind of attributeToNameIdMapper but
I have to admit that I'm lost a bit in the code.
Do you think this approach is good ?
Best regards, Jérôme.
Le mer. 6 janv. 2016 à 09:31, Jérôme Blanchard <jayblanc(a)gmail.com
<mailto:jayblanc@gmail.com>> a écrit :
Hi Bill, all,
In the case of a transient only nameid, would it be possible to
create a dedicated attribute mapper in order to use for exemple
the email attribute as name identifier ?
PS : the urn:mace:shibboleth:1.0:nameIdentifier is in fact use in
SAML v1 for request a nameid that is transient also... so there is
no solution in this way.
Best regards, Jérôme.
Le mar. 5 janv. 2016 à 16:13, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> a écrit :
We won't be able to support temporary ids (transient) for
awhile as it
requires temporary user creation which requires some
rearchitecting.
As for "urn:mace:shibboleth:1.0:nameIdentifier" if you spec it
out in a
JIRA and it is simple enough to implement support for, we may
be able to
get it in.
On 1/5/2016 8:18 AM, Jérôme Blanchard wrote:
> Hi Bill,
>
> Thanks for your answer regarding transient and temporary ids. I
> understand the problem due to keycloak account creation and
binding to
> the IdP.
> Renarter is using Shibboleth ; Is there is any work on
shibboleth
> integration for keycloak ?
> If I look into the idps entities descriptors of renater, I
found that it
> uses also another nameid format based on shibboleth namesapce :
>
<md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat>
>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
>
> Do you think it is possible to patch the saml idp provider
(or to create
> another one dedicated to shibboleth) in order to integrate
keycloak to
> our identity federation (renater) ?
>
> Best whiches for this upcoming year and thanks for your
great work
> around keycloak.
>
> Jérôme.
>
>
> Le mar. 22 déc. 2015 à 21:10, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>
> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> a
écrit :
>
> Our brokering doesn't support temporary user ids from
the "parent" IDP.
> Transient Ids in SAML or temporary ids.
>
> On 12/22/2015 11:46 AM, Jérôme Blanchard wrote:
> > Hi,
> >
> > I'm trying to integrate keycloak into a the french
research
> federation
> > of identity (renater) and I'm facing some problems.
> > Actually, when IdP respond to keycloak i'm getting
the following
> error :
> > PL00084: Writer: Unsupported Attribute
> > Value:org.keycloak.dom.saml.v2.assertion.NameIDType
> >
> > It seems that this IdP is using transient NameID
policy only and
> using
> > the unspecified field in the idp config in keycloak
generate this
> > exception as a return.
> >
> > Log of the keycloak server is joined.
> >
> > I have no idea of what happening because when I was
using the test
> > federation, everything was working but no I'm in the
production
> > federation, login fails.
> >
> > The renater federation is using Shibolleth and
keycloak is not
> supported
> > by federation moderators so I'm alone in the dark now...
> >
> > Renater provides an IdP list that I have to parse and
> synchronized with
> > IdP in keycloak. As a return I provide a list of all
endpoints
> for each
> > keycloak registered IdP to allow federation IdP to
answear
> correctly to
> > the right endpoint. All of this is done by a small
web app deployed
> > aside keycloak and using REST API to synchronize all
the IdP.
> >
> > One of the IdP entity descriptor is joined. As you
can see, only
> > transient nameid policy is supported and if I
configure keycloak
> to use
> > email or persistent, I received a response saying
that the nameid
> is not
> > supported :
> >
> > <samlp:AuthnRequest
> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> > xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
> >
>
AssertionConsumerServiceURL="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint"
> >
Destination="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO"
> > ForceAuthn="false"
ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d"
> > IsPassive="false"
IssueInstant="2015-12-22T16:13:15.987Z"
> >
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> > Version="2.0"><saml:Issuer
> >
>
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://demo-auth.ortolang.fr/auth/realms/ortolang</saml:Issuer><samlp:NameIDPolicy
> > AllowCreate="true"
> >
>
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest>
> >
> >
> > <saml2p:Response
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
> >
>
Destination="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint"
> > ID="_9d03761957aade819b6823c35bbab278"
> > InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d"
> > IssueInstant="2015-12-22T16:13:16.420Z"
Version="2.0"><saml2:Issuer
> > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
> >
>
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://janus.cnrs.fr/idp</saml2:Issuer><saml2p:Status><saml2p:StatusCode
> >
>
Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode
> >
>
Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required
> > NameID format not
> >
supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response>
> >
> >
> > Any help would be gracefully appreciated.
> >
> > Thanks a lot, Jérôme.
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
<mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
<mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com