Keycloak 3.4.3 - Importing Terms and Conditions Required Action
by McDonnell, John
Hi,
I’m working on an integration project against Keycloak 3.4.3-FINAL, and so am limited to what KeyCloak version in use.
At the moment I have spotted that when I import realm settings as JSON via rest, the terms and conditions required actions enabled/defaultAction settings are not being considered.
I am using the API: HTTP PUT: "<keycloak_url>/auth/admin/realms/R6", where R6 is the realm I’m updating, and the content of the update I’m trying is:
{
"realm": "R6",
"loginTheme": "btcms-default",
"accountTheme": "r6-default",
"emailTheme": "btcms-default",
"passwordPolicy": "regexPattern(^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*[$@$!?&])[A-Za-z\\d$@$!?&]{8,32}) and forceExpiredPasswordChange(90) and passwordHistory(3)",
"resetPasswordAllowed": true,
"requiredActions": [
{
"alias": "CONFIGURE_TOTP",
"name": "Configure OTP",
"providerId": "CONFIGURE_TOTP",
"enabled": true,
"defaultAction": false,
"config": {}
},
{
"alias": "UPDATE_PASSWORD",
"name": "Update Password",
"providerId": "UPDATE_PASSWORD",
"enabled": true,
"defaultAction": false,
"config": {}
},
{
"alias": "UPDATE_PROFILE",
"name": "Update Profile",
"providerId": "UPDATE_PROFILE",
"enabled": true,
"defaultAction": false,
"config": {}
},
{
"alias": "VERIFY_EMAIL",
"name": "Verify Email",
"providerId": "VERIFY_EMAIL",
"enabled": true,
"defaultAction": false,
"config": {}
},
{
"alias": "terms_and_conditions",
"name": "Terms and Conditions",
"providerId": "terms_and_conditions",
"enabled": true,
"defaultAction": true,
"config": {}
}
]
}
The issue I’m seeing in the UI is that the terms and conditions require actions is disabled. I can change this in the UI, and export, which exports this correctly, but I am unable to import this configuration. Is there something else needed to configure required actions?
Regards
John McDonnell
Manager
[signature_831592184]
BearingPoint
Montague House
Adelaide Road
Dublin
D02 K039
Ireland
john.mcdonnell(a)bearingpoint.com <mailto:john.mcdonnell@bearingpoint.com>
www.bearingpoint.com<http://www.bearingpoint.com>
________________________________
BearingPoint Ireland uc
registered in Dublin, Ireland No. 489298.
Registered office: Montague House, Adelaide Road, Dublin 2.
The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
8 years, 1 month
Custom SPI Deployment v4.3.0
by gambol
Hiya
I've checked the release document but nothing stands out .. Has anything
changed in the way SPI are deployed in keycloak 4.3.0 Final?
As part of the image build we'd copy a number of jars in the
keycloak/providers/ directory (event logs, prometheus metrics, a custom
authenticator etc) which in 4.2.1 is working fine, but in v4.3.0 is doesn't
appear to find anything.
Rohith
8 years, 1 month
Re: [keycloak-user] Limitations of create_realm role or a bug?
by Christian Neudert
Hi,
Has someone an opinion on this? Should I create a bug for it?
Best regards,
Christian Neudert
On 16.08.18, 12:07, "keycloak-user-bounces(a)lists.jboss.org on behalf of Christian Neudert" <keycloak-user-bounces(a)lists.jboss.org on behalf of christian.neudert(a)doksafe.de> wrote:
Hello,
I have a permission problem with realms created by an user in the master realm, who has the “create_realm” role only. This user can create a realm and new users in it but can’t assign the “impersonation” role to them. From my understanding, it’s because this user doesn’t have the “impersonation” role in the master realm and therefor can’t assign it to another user in another realm. This is expected as of what’s written in https://www.keycloak.org/docs/3.4/server_admin/index.html#realm-specific-....
My problem is that I can’t configure the created realm completely with this user without that posibility. It also contradicts what’s written in https://www.keycloak.org/docs/3.4/server_admin/index.html#global-roles: “Users with the create-realm role are allowed to create new realms. They will be granted full access to any new realm they create.“.
Should a user with the ‘create_realm’ role be allowed to set the ‘impersonation’ role for users in realms created by her or is it a bug? If it’s a wanted restriction I don’t know how to solve that problem without giving this user the admin permission in the master realm which is… not so good.
FYI: I’m using Keycloak 3.4 with the Java Keycloak Admin CLI atm.
Best regards,
Christian Neudert
________________________________
[https://www.actaport.de/images/doksafe_mailclosing_actaport.jpg]<https://www.actaport.de?utm_source=email&utm_medium=mail_disclaimer&utm_c...>
Kanzleisoftware für moderne Anwälte
Kostenlos testen unter www.actaport.de<https://www.actaport.de?utm_source=email&utm_medium=mail_disclaimer&utm_c...>
________________________________
[https://www.actaport.de/images/doksafe_logo_200.png]
dokSAFE GmbH
Goethestraße 1
04109 Leipzig
www.doksafe.de<https://www.doksafe.de?utm_source=email&utm_medium=mail_disclaimer&utm_ca...>
________________________________
Sitz der Gesellschaft: Goethestraße 1, 04109 Leipzig
Amtsgericht Leipzig HRB 32536, Geschäftsführer Steffen Scholz, Dr. Michael Schäfer
________________________________
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
________________________________
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information.
If you have received this e-mail in error, you are hereby notified that any review,
copying, or distribution of it is strictly prohibited.
Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
________________________________
doksafe GmbH: Goethestraße 1, 04109 Leipzig
Amtsgericht Leipzig HRB 32536, Geschäftsführer Steffen Scholz, Dr. Michael Schäfer
________________________________
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
________________________________
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information.
If you have received this e-mail in error, you are hereby notified that any review,
copying, or distribution of it is strictly prohibited.
Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
________________________________
[https://www.actaport.de/images/doksafe_mailclosing_actaport.jpg]<https://www.actaport.de?utm_source=email&utm_medium=mail_disclaimer&utm_c...>
Kanzleisoftware für moderne Anwälte
Kostenlos testen unter www.actaport.de<https://www.actaport.de?utm_source=email&utm_medium=mail_disclaimer&utm_c...>
________________________________
[https://www.actaport.de/images/doksafe_logo_200.png]
dokSAFE GmbH
Goethestraße 1
04109 Leipzig
www.doksafe.de<https://www.doksafe.de?utm_source=email&utm_medium=mail_disclaimer&utm_ca...>
________________________________
Sitz der Gesellschaft: Goethestraße 1, 04109 Leipzig
Amtsgericht Leipzig HRB 32536, Geschäftsführer Steffen Scholz, Dr. Michael Schäfer
________________________________
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
________________________________
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information.
If you have received this e-mail in error, you are hereby notified that any review,
copying, or distribution of it is strictly prohibited.
Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
8 years, 1 month
How to get java libraries
by Robert Smol
Hi,
where do I get Java libraries so I can develop against the Keycloak? I
would like to implement some interfaces from `org.keycloak.storage` but I
cannot find those anywhere.
I've looked at
https://www.keycloak.org/docs/latest/server_development/index.html but
there is no such information.
I am new to Java, but I know I either need to provide some jar files or use
gradle/maven to load the modules?
Thanks,
Robert
8 years, 1 month
Re: [keycloak-user] Keycloak Proxy Rename
by Jan Garaj
(auth) "proxy" is a common and well-known name for this type of component -
for example https://github.com/bitly/oauth2_proxy ,
http://docs.grafana.org/tutorials/authproxy/.
See Google trends:
https://trends.google.com/trends/explore?q=auth%20proxy,auth%20adapter,au...
Github repo/code stat shows "proxy" preference as well.
What I don't like is a "keycloak" in the name - actually it's a generic
"proxy" implementation, which works with (almost) any OpenID provider.
There is no "keycloak" project lock-in at the moment.
My current prefered name is "OAuth Standalone Proxy" from Keycloak project,
repo keycloak/oauth-standalone-proxy.
A similar case is etcd from coreos project, repo coreos/etcd - you really
don't need to keep organization name in the project name.
*Jan Garaj*
Web: http://www.jangaraj.com / http://monitoringartist.com
LinkedIn: http://www.linkedin.com/in/jangaraj
On Mon, Aug 20, 2018 at 9:30 PM <keycloak-user-request(a)lists.jboss.org>
wrote:
> ---------- Forwarded message ----------
> From: Bruno Oliveira <bruno(a)abstractj.org>
> To: Hynek Mlnarik <hmlnarik(a)redhat.com>
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>, keycloak-user <
> keycloak-user(a)lists.jboss.org>
> Bcc:
> Date: Mon, 20 Aug 2018 12:54:42 -0300
> Subject: Re: [keycloak-user] Keycloak Proxy Rename
> Only to give a brief context for people not aware of it. Keycloak
> Generic Adapter was not well accepted, because the naming is too
> vague. So we have to reopen this discussion and think about a better
> naming.
>
> During our team call today I suggested just "keycloak-adapter", which
> would cover the apps which don't have its own specific adapter
> solution.
>
> That said, maybe we should open a new poll? I just created a new one
> where people can vote/suggest:
>
> https://poll.ly/#/Lbww4ebG
>
>
> On Mon, Aug 20, 2018 at 10:38 AM Hynek Mlnarik <hmlnarik(a)redhat.com>
> wrote:
> >
> > Based on discussion on Stian, let me reopen this topic and add a
> suggestion.
> >
> > How about "Standalone Keycloak Adapter" or just "Standalone Adapter"?
> >
> >
> > On Mon, Jun 25, 2018 at 5:44 PM Bruno Oliveira <bruno(a)abstractj.org>
> wrote:
> >>
> >> Good afternoon,
> >>
> >> We are considering to transfer or fork the keycloak-proxy[1] to Keycloak
> >> organization. In order to accomplish that, I've been working with Rohith
> >> updating some of its dependencies[2].
> >>
> >> While discussing with our team, we reached the conclusion that call it a
> >> proxy could potentially increase the scope of the project and also give
> >> people the wrong idea. Because would be expected things like load
> balancing,
> >> rate limiting, and other features. That's not what we want right now.
> >>
> >> I would like to gather some feedback from the community before we move
> forward.
> >> So please vote on the following Doodle:
> >>
> >> https://doodle.com/poll/gux626ktscgpr96t
> >>
> >> Also, feel free to suggest other names and it will be included.
> >>
> >> [1] - https://github.com/gambol99/keycloak-proxy
> >> [2] - https://issues.jboss.org/browse/KEYCLOAK-7265
> >>
> >>
> >> --
> >>
> >> abstractj
> >> _______________________________________________
>
8 years, 1 month
Re: [keycloak-user] How to logout
by Ryan Slominski
I need the Wildfly client adapter because database lookups are provided by the server.
I think I've found a JIRA related to the logout issue:
https://issues.jboss.org/browse/KEYCLOAK-2939
Taking a cue from the issue ticket above I noticed that if I create my own hidden iframe and navigate to the keycloak logout URL from within it then the logout works. Using a XMLHttpRequest (AJAX) request to the logout URL wasn't working, but the hidden iframe does. Weird. Must be something to do with cross-site scripting / cookies?
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "Ryan Slominski" <ryans(a)jlab.org>
Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Monday, August 20, 2018 2:34:17 PM
Subject: Re: [keycloak-user] How to logout
On 8/20/2018 9:27 AM, Ryan Slominski wrote:
> I'm starting to wonder if the Wildfly client adapter is implemented all wrong. Doesn't it make more sense to have the state maintained in the web browser using the JavaScript client (since only the browser can really know the state) and then having a stateless server that uses bearer tokens to determine if web service requests are authenticated and authorized? There should be no JSESSIONID at all.
I don't think that makes sense. If you want everything handled in the
browser then you can use the javascript adapter.
If you absolutely need to know the Keycloak session state without making
a server request then javascript adapter would be the solution. In that
case, you wouldn't use the WildFly adapter at all.
8 years, 1 month
Re: [keycloak-user] How to logout
by Ryan Slominski
I'm starting to wonder if the Wildfly client adapter is implemented all wrong. Doesn't it make more sense to have the state maintained in the web browser using the JavaScript client (since only the browser can really know the state) and then having a stateless server that uses bearer tokens to determine if web service requests are authenticated and authorized? There should be no JSESSIONID at all.
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "Ryan Slominski" <ryans(a)jlab.org>
Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Friday, August 17, 2018 8:25:53 AM
Subject: Re: [keycloak-user] How to logout
On 8/16/2018 8:41 AM, Ryan Slominski wrote:
> I've enabled backchannel logout in the brokered identity providers, and I've confirmed it keeps all of the brokered identity providers in sync. For example if I log into my broker 3 IdP and logout of my realm then I'm also logged out of broker IdP 3. So, backchannel logout seems to work with the link between the realm and brokered identity providers. However, unless I'm not understanding backchannel logout, it doesn't affect clients who manage their own session state such as the Wildfly client adapter, which creates an independent JSESSIONID cookie to store session state. So right now logging out of application A does destroy the Keycloak token, but if a login with application B was already established then it remains locally logged in even after application A is logged out. Is that not how it is supposed to work? If not, how do I configure a Wildfly client to honor another application's logout?
I would have to study the code a bit to know the specifics. I'm
guessing that backchannel logout doesn't invalidate the local session as
you suggest. That might be a little too intrusive, though the app
developer could handle it with an HttpSessionListener.
But it seems to me that you should be able to just use isUserInRole()
with each request and then act accordingly. If you log out of
application A then isUserInRole() on application B should always return
false.
>
> ----- Original Message -----
> From: "Stan Silvert" <ssilvert(a)redhat.com>
> To: "Ryan Slominski" <ryans(a)jlab.org>
> Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
> Sent: Thursday, August 16, 2018 7:44:01 AM
> Subject: Re: [keycloak-user] How to logout
>
> On 8/15/2018 4:34 PM, Ryan Slominski wrote:
>> Two issues:
>>
>> (1) Wildfly client adapter doesn't detect when a user is logged into Keycloak on pages in which HttpServletRequest.isUserInRole() method is used to programmatically determine who sees what until after hitting a declaratively protected (web.xml) page first. Wildfly client adapter assumes all pages which use isUserInRole are declaratively protected, but that is not always true (and essentially never true in my case). This means when jumping from one application to another you lose your SSO.
> If you are correct about isUserInRole() then the WildFly adapter needs
> to be fixed.
>
> What should happen is that when you logout of application A then the
> Keycloak server sends a backchannel logout to application B. At that
> point, a call to isUserInRole() from application B should return false.
>
> Do you have backchannel logout working?
>
>> (2) Trying to switch users in an environment where it is unknown whether you are logged in or not results in surprise logins as the previous account when you really want to enter new credentials
>>
>> Essentially all my application pages show something no matter if you are logged in or not, but if you are logged in you see extra stuff like edit buttons. When working in a group around a computer and someone asks to switch users (login as admin or move over and let me show you scenarios) confusion ensues as the application might show the user as not logged in, but then attempting to login detects existing token and skips login form. Now user must logout and try again.
>>
>>
>> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>> To: "Ryan Slominski" <ryans(a)jlab.org>
>> Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
>> Sent: Wednesday, August 15, 2018 4:04:03 PM
>> Subject: Re: [keycloak-user] How to logout
>>
>> On 8/15/2018 3:27 PM, Ryan Slominski wrote:
>>> Hi Stan,
>>> If you have multiple applications you can get out-of-sync. If you open application A in one browser tab, login, and then navigate to application B in another browser tab then application B is now out of sync with keycloak until you hit a "protected" page. The problem arises because I use programmatic security instead of declarative security:
>> I don't understand why this matters. If you are not going to a
>> protected page in application B then why do you care if you are logged
>> into Keycloak?
>>
>> I guess I'm not understanding your use case.
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_tut...
>>>
>>> And it looks like the Wildfly client adapter doesn't handle users of programmatic security in that it doesn't detect if a SSO token exists on pages which are not declaratively protected (actually programmatic security doesn't work at all with the Keycloak adapter and I am faking it by redirecting users off of a dummy declaratively protected URL). It might be possible to have a Servlet filter do a check with the keycloak server on each request, but that would be costly. The JavaScript client has a huge advantage because it can watch the keycloak cookie presence via a hidden iframe. In fact, I realize now exposing the confidential client secret in a form client side is not a good idea. It seems like to do what I want (track SSO state across multiple tabs and multiple applications) I might have to actually have two "clients" per application: (1) on the web server side and (2) another on the browser client side. The browser client side can then detect the actual state of SSO. Or maybe I can have a single JavaScript client that is shared among multiple server side Keycloak clients and handles tracking SSO state and provides the information as a service. Maybe this is built-in to keycloak server itself?
>>>
>>> Ryan
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>> To: "Ryan Slominski" <ryans(a)jlab.org>
>>> Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
>>> Sent: Wednesday, August 15, 2018 3:02:18 PM
>>> Subject: Re: [keycloak-user] How to logout
>>>
>>> Why is your client out of sync with the keycloak server? If you are
>>> building a servlet-based application (JSF, JSP, Struts, etc.), then why
>>> not use the WildFly adapter in the JEE way as described in the Keycloak
>>> documentation? The WildFly Keycloak adapter takes care of all the hard
>>> stuff for you.
>>>
>>> On 8/15/2018 9:50 AM, Ryan Slominski wrote:
>>>> Hi Stan,
>>>> The documentation doesn't mention this, but it seems the logout URL should be a POST, not a GET request. Is that true?
>>>>
>>>> So, I'm trying to create an HTML logout form with method post and action to the documented logout URL. The form has a submit button and two hidden fields: "client_id" and "client_secret". Clicking the submit button results in the following JSON response from the keycloak server:
>>>>
>>>> {"error":"invalid_request","error_description":"No refresh token"}
>>>>
>>>> So, I guess I need a third field, something like "refresh_token"? How would I get a refresh token? Remember I'm using the Wildfly client adapter and in my scenario the client is out-of-sync with the keycloak server (the user is logged into keycloak, but not the local client).
>>>>
>>>> Thanks,
>>>>
>>>> Ryan
>>>>
>>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>>> To: "keycloak-user" <keycloak-user(a)lists.jboss.org>
>>>> Sent: Monday, August 13, 2018 7:15:15 PM
>>>> Subject: Re: [keycloak-user] How to logout
>>>>
>>>> HttpServletRequest.logout() should not be a no-op. It was implemented a
>>>> long time ago:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro...
>>>>
>>>> If there is an issue with it you should report it in JIRA.
>>>>
>>>> Stan
>>>>
>>>> On 8/13/2018 4:19 PM, Ryan Slominski wrote:
>>>>> Hi Keycloak Users,
>>>>>
>>>>> I'm using the Wildfly client adapter and trying to logout of Keycloak, even if a client application container doesn't think it is logged in. This is a problem because login state with Keycloak and login state with JSESSION_ID in servlet container are two separate things that can get out-of-sync. The documentation says you can logout in one of two ways:
>>>>>
>>>>> 1. Call HttpServletRequest.logout()
>>>>> 2. Navigate to URL https://urldefense.proofpoint.com/v2/url?u=http-3A__auth-2Dserver_auth_re... {realm-name}/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri
>>>>>
>>>>> See: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.keycloak.org_doc...
>>>>>
>>>>> The first appears to be a no-op because the Java container itself isn't logged in, in this case. This does work if the client container is aware that it is logged in, but doesn't otherwise. The second also doesn't seem to do anything and just redirects back to redirect_uri. Any tips?
>>>>>
>>>>> A forceful logout is useful in the scenario when one client (client A) logs into Keycloak, and a different client (cilent B) wants to forcefully logout as to switch users. In this scenario client B doesn't think it is logged in because the client adapter is using container managed security with JSESSIONID, and locally the client isn't logged in. However if a login was attempted it would succeed automatically without prompting for a username and password and therefore the user wouldn't get a chance to provide an alternate username. A switch user ability is useful when users need to login with separate admin credentials or also in scenarios where a user says "move over and I'll drive" to a colleague.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ryan
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user(a)lists.jboss.org
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
8 years, 1 month
IDP SAML Processing Error
by Yildirim, Suleyman
Hi,
I have a "Uncaught server error: org.keycloak.broker.provider.IdentityBrokerException: Could not process response from SAML identity provider" when get response from MS ADFS server. The route cause of the error is Caused by: java.io.IOException: Short read of DER length. So I suspect that Validating X509 Certificates input box doesn't work as expected in Keycloak: "Certificates must be in PEM format and multiple certificates can be entered by comma (,) ". I have to use Public key and the certificates of the realm separated by comma but I get 500 - Internal Server Error from MS ADFS server and the error in Keycloak (Attached file: IDP_error.txt). If I only use realm certificate, I get invalid requester error. Any idea of how I can proceed?
Details
When I use dummy IDP of Keycloak server, I use https://myapplicationurl/auth/realms/springboot-quickstart/protocol/saml as SSO url, "email" as "NameID Policy Format" (Attached file: dummyIDPSettings.png). As for real ADFS integration, I setup everything according to that blog http://blog.keycloak.org/2017/03/how-to-setup-ms-ad-fs-30-as-brokered.html and use the client's SSO url (Attached file: ADFSIDPSettings.png). I think I did everything right. Keycloak endpoints, SSL keystore and truststore files are at the right locations and places.
Regards,
Suleyman
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________
www.accenture.com
8 years, 1 month
keycloak 4.2.1 saml adapater
by vandana thota
Hello
We have built wildfly 11.0.0 RPM
Sceanrio 1 : Is it good way to have keycloak -saml-adapter 4.2.1
related stuff in wildfly rpm or
Scenario 2 : its good to have wildfly 11.0.0. rpm as separate and keycloak
-saml adapter 4.2.1 rpm separate ?
Please send the details with pros and cons for both scenarios
8 years, 1 month
