1:09 p.m.
I think what I'm trying to understand is your IDP-initiated use case.
Assuming that a user has already been authenticated as part of some other
webapp, how does the IDP transition to our web app in that circumstance?
=================================
*Craig Setera*
*Chief Technology Officer*
On Mon, Oct 15, 2018 at 3:44 AM Dmitry Telegin <dt(a)acutus.pro> wrote:
Hi Craig,
On Fri, 2018-10-12 at 10:47 -0500, Craig Setera wrote:
> Dmitry,
>
> This is great! I was able to finally see a working SAML identity broker
and I can therefore, start to understand how it works.
You're welcome :) SAML with all its quirks is sometimes hard to grok even
for seasoned engineers.
> One other question: I understand how to provide a "hint" about which
identity provider to use when initiating login from my client application.
Do you mean the kc_idp_hint URL parameter? You should remember that it
will work only with OpenID Connect clients.
More info here: https://issues.jboss.org/browse/KEYCLOAK-4884
> Is there a way to "start" login at the SAML service and have it redirect
back to Keycloak or must the login processing always start at Keycloak?
I'm afraid I don't fully understand what is meant by "SAML service"
here.
In SAML lexicon, there are Service Providers (SPs) and Identity Providers
(IDPs).
In the simplest scenario, your web application is an SP, and Keycloak is
an IDP.
You access your webapp, get redirected to Keycloak, pass authentication,
get redirected back and allowed to access the app. This is called
"SP-initiated login" in SAML parlance.
You can also go to a special URL inside Keycloak, be taken to login screen
immediately, and upon successful login redirected to your webapp. This is
called "IDP-initiated login".
Both scenarios are possible with brokering, where Keycloak also poses as
an SP for a 3rd party IDP.
SP-initiated workflow will look like the following:
webapp -> Keycloak -> 3rd party IDP -> (Keycloak, transparently) -> webapp
IDP-initiated:
3rd party IDP -> (Keycloak, transparently) -> webapp
Does any of the above resemble your use case?
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info(a)acutus.pro
>
> Thanks again,
> Craig
>
> =================================
> Craig Setera
> Chief Technology Officer
>
>
>
>
> > On Fri, Oct 12, 2018 at 7:50 AM Dmitry Telegin <dt(a)acutus.pro> wrote:
> > Hi Craig,
> >
> > On Thu, 2018-10-11 at 15:36 -0500, Craig Setera wrote:
> > > I'm attempting to set up a test of identity brokering all within a
single
> > > Keycloak server. I have two realms set up. The "saml-demo"
realm
is set
> > > up with a SAML client. I've exported the SAML definition from that
client
> > > and imported it into the Identity Brokering for the second realm.
> >
> > In the brokering scenario, your webapp should remain the client of the
saml-demo realm, and this realm itself should become a client of another
realm. This is how brokering actually works.
> >
> > Let's assume there are realms "foo" and "bar", and the
former should
broker to the latter. The exact steps are:
> > 1. Go to "foo" realm -> Identity Providers -> add SAML 2.0
provider;
> > 2. Scroll down to "Import from URL", enter the following:
> > http://
<your-keycloak-host>:<port>/auth/realms/bar/protocol/saml/descriptor
> > (replace "bar" with the actual name of your second realm)
> > 3. Go to Export tab, save EntityDescriptor XML;
> > 4. Go to "bar" realm -> Clients, create one, import the XML from
the
previous step, provide some meaningful name;
> > 5. Create some users in "bar".
> >
> > After that, try accessing your SAML client. You'll be presented with
the Keycloak login screen where you'll be able to either authenticate
against "saml-demo", or to choose another realm.
> >
> > Some notes:
> > - you can avoid first login screen and redirect automatically to the
second realm, using custom authentication flow with IDP redirector + flow
override at the client level;
> > - upon the first brokered login, the user will be presented with the
Update account details screen. If you want to bypass that, you can enable
identity auto-linking.
> > It's out of the box in KC 4.5.0, thx to excellent work by Ryan
Slominski: https://issues.jboss.org/browse/KEYCLOAK-7270
> > For KC <4.5.0, you can use this:
https://github.com/ohioit/keycloak-link-idp-with-user
> >
> > Good luck!
> > Dmitry Telegin
> > CTO, Acutus s.r.o.
> > Keycloak Consulting and Training
> >
> > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> > +42 (022) 888-30-71
> > E-mail: info(a)acutus.pro
> >
> > > Unfortunately, I can't seem to get to the login page of the
"saml-demo"
> > > when navigating from the second realm. When I click on the identity
broker
> > > realm link, I'm seeing the following in the logs:
> > >
> > > keycloak_1 | Caused by: java.security.SignatureException: Signature
length
> > > not correct: got 256 but was expecting 128
> > > keycloak_1 | at
> > > sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)
> > > keycloak_1 | at
> > > java.security.Signature$Delegate.engineVerify(Signature.java:1222)
> > > keycloak_1 | at
java.security.Signature.verify(Signature.java:655)
> > > keycloak_1 | at
> > >
org.apache.jcp.xml.dsig.internal.dom.DOMSignatureMethod.verify(DOMSignatureMethod.java:236)
> > >
> > > I've turned up logging for all of the Keycloak SAML functionality as
well
> > > as for java.security. However, I'm struggling to figure out where
the
> > > mismatch is located in the configuration and not quite sure where to
even
> > > look.
> > >
> > > Can anyone offer suggestions on how to go about setting this up or
> > > troubleshooting what I'm doing?
> > >
> > > Thanks,
> > > Craig
> > >
> > > =================================
> > > *Craig Setera*
> > >
> > > *Chief Technology Officer*
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >