[keycloak-user] Problem using SAML IdP
Bill Burke
bburke at redhat.com
Thu Jan 14 09:23:35 EST 2016
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 at gmail.com
> <mailto:jayblanc at 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 at redhat.com
> <mailto:bburke at 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 at redhat.com
> <mailto:bburke at redhat.com>
> > <mailto:bburke at redhat.com <mailto:bburke at 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 at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
> <mailto:keycloak-user at lists.jboss.org
> <mailto:keycloak-user at 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 at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
> <mailto:keycloak-user at lists.jboss.org
> <mailto:keycloak-user at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160114/63418529/attachment-0001.html
More information about the keycloak-user
mailing list