Scope parameter support
by Marek Posolda
It seems that for OIDC certification, we will need more proper support
for "scope" parameter. There are few tests from OIDC conformance
testsuite, which end with WARNING because of issues with "scope" parameter.
SUMMARY OF SPECS REQUIREMENTS
-----------------------------
- In OIDC specification, the "scope" parameter is actually REQUIRED. And
you must add the scope value "openid" to all authorization requests.
Hence if you don't use "scope=openid", the request is pure OAuth2
request, but it's not OIDC request.
In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the
possibility that we should change our adapters and add "scope=openid" to
all requests, and also the possibility to remove IDToken if it's not
OIDC request (and maybe other things). However it may be potential issue
with backward compatibility with older adapters (which don't add
"scope=openid" at all).
- OIDC also prescribes the "scope=offline_access", which you use if you
want offline token. We actually support this as we have realm role
"offline_access", with scopeParamRequired=true . So this role is applied
just if it's included in scope parameter. This is our only support of
scope param actually. ATM we reference the realm roles by name (role
name must match the value of scope parameter) and clientRoles by
"clientId/roleName" . So it's not very flexible and won't work well in
the future with role namespaces.
- OIDC defines four other scope values, which we don't support, with the
meaning like this:
profile
OPTIONAL. This scope value requests access to the End-User's
default profile Claims, which are: "name", "family_name", "given_name",
"middle_name", "nickname", "preferred_username", "profile", "picture",
"website", "gender", "birthdate", "zoneinfo", "locale", and "updated_at".
email
OPTIONAL. This scope value requests access to the "email" and
"email_verified" Claims.
address
OPTIONAL. This scope value requests access to the "address" Claim.
phone
OPTIONAL. This scope value requests access to the "phone_number"
and "phone_number_verified" Claims.
- Not directly related to scopes, however OIDC also has one parameter
"claims" described in section
http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter .
This allows to define some additional claims, which should be included
in IDToken or UserInfo endpoint in addition to claims specified by
"scope" parameter.
HOW TO IMPLEMENT?
-----------------
My current thinking is, that we will have 2 kinds of protocolMappers and
roles.
1) "Always applied" - Those roles/protocolMappers are always applied to
token even if they are not specified by scope parameter.
2) "Applied on demand" - Those roles/protocolMappers are applied just if
they are specifically requested by scope parameter
For roles, we already have that with "scope param required" flag defined
per roleModel. However for protocolMappers we don't have it yet.
IMO We will also need some more flexible way to specify how the value of
scope parameter will be mapped to roles and protocolMappers. For example
if I use "scope=foo", it can mean that I want realm role "foo1", client
role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc.
I can see 2 possibilities:
a) Configure allowed scope param separately per each role / protocolMapper
If some role has "Scope param required" checked, you will have
possibility to configure list of available values of scope parameter,
which this role will be applied to. This will be configured per-each
role separately.
Example: I have realm role "foo" . I check "scope param required" to
true. Then I will define "scope param values" : "bar" and "baz". It
means that if someone uses parameter "scope=bar" or
scope=baz", then role "foo" will be applied to token. Otherwise it won't
be applied.
Similarly it will be for protocolMappers. We will add switch "Scope
param required" to protocolMappers and we will use list of available
values of scope parameter, which is configured per each protocolMapper
separately.
b) Configure scope parameter in separate place
We will have another tab "Scope parameter config" (or maybe rather
another sub-tab under existing "Scope" tab). Here you will define the
allowed values of scope parameter. For each allowed value, you will
define protocolMappers and roles to apply. Hence for example for
"profile" scope parameter, you will define all protocolMappers for
corresponding claims ( name, family_name, ...) here.
We will still need "scope param required" switch for protocolMappers in
case (b).
My current thinking is to go with (a). So when you go to some role (or
protocolMapper) in admin console you will see if you need scope
parameter and what are available values of scope parameter to request it.
WDYT? Another ideas?
Marek
6 years, 3 months
Getting error with authentication using ecp.sh script
by Rashmi Singh
Hi All,
I am using ecp.sh (provided by keycloak team, ofcourse with changes on
idp_endpoint based on my keycloak environment) to perform authentication.
I am using spring saml SP and keycloak IDP. I enabled ecp on the SP side
and then I execute ecp.sh script as:
./ecp.sh -d rhsso http://192.168.99.100:8888/saml-sp/first.jsp newuser4
My idp_endpoint is: "
http://192.168.99.100:9990/auth/realms/xxxxxxxxxx/protocol/saml"
where xxxxxxxxxx is my realm (replaced my realm with xxxxxxxxxx for this
email)
The script prompts me to enter password and then it sends an auth request
to keycloak IDP.
Now, something goes wrong at the IDP.
I enabled saml logs on keycloak to see the incoming request and the
following error from the logs:
00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-2)
SAML POST Binding
00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-2)
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://192.168.99.100:8888/saml-sp/saml/SSO"
ForceAuthn="false" ID="a31ah57718g27gd149da6jeb08620ig" IsPassive="false"
IssueInstant="2016-12-24T00:51:34.799Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#a31ah57718g27gd149da6jeb08620ig">
<ds:Transforms>
<ds:Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>nfLQ9IFs9IFnSgw3HHHKuPkAbRY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>iULSwpjBb38Vmtan4ZIocRx4PNr6fHRuhVbL+7yXNz3wqjlSavtk7haUiADwUS2cTofRM5KDzUvIkaQPXBZqEkz2xnrhpNj71eIqJ6H4ZqW3mpvP8Bk9z3VEmcEQhZSd6j8rMf4JOdIBRtE7cea0wJhuQ1UdsHdcKeIdp+wuRvn8t9vS/mPKd9GAt11JpC+bgMQS0MDy+r1+AZof2+XMyMuwECVIkouTzwlgKDEmgvQh6Aq61f+QzIeeZ9+3efwJyIH61x7J4CaiSTpesezlXx8UQnqIL+AToL1OFHSp2bgXXxkP1rHSkyNM34Eg92LmI5cN3oBfQDR8r+mCoEctWA==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDUjCCAjqgAwIBAgIEUOLIQTANBgkqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEyODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7KqxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pONUUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBuRogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEWbHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/GuHE=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml2p:AuthnRequest>
00:51:41,265 DEBUG [org.keycloak.saml.common] (default task-2) The provider
ApacheXMLDSig - 2.05 was added at position: 2
00:51:41,545 WARN [org.keycloak.services] (default task-2)
KC-SERVICES0013: Failed authentication:
org.keycloak.authentication.AuthenticationFlowException
at
org.keycloak.authentication.DefaultAuthenticationFlow.processResult(DefaultAuthenticationFlow.java:242)
at
org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:185)
at
org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:792)
at
org.keycloak.protocol.AuthorizationEndpointBase.handleBrowserAuthenticationRequest(AuthorizationEndpointBase.java:100)
at
org.keycloak.protocol.saml.SamlService.newBrowserAuthentication(SamlService.java:505)
at
org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService.newBrowserAuthentication(SamlEcpProfileService.java:89)
at
org.keycloak.protocol.saml.SamlService.newBrowserAuthentication(SamlService.java:501)
at
org.keycloak.protocol.saml.SamlService$BindingProtocol.loginRequest(SamlService.java:297)
at
org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService$1.loginRequest(SamlEcpProfileService.java:72)
at
org.keycloak.protocol.saml.SamlService$BindingProtocol.handleSamlRequest(SamlService.java:209)
at
org.keycloak.protocol.saml.SamlService$PostBindingProtocol.execute(SamlService.java:453)
at
org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService.authenticate(SamlEcpProfileService.java:74)
at
org.keycloak.protocol.saml.SamlService.soapBinding(SamlService.java:619)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
00:51:41,548 WARN [org.keycloak.events] (default task-2) type=LOGIN_ERROR,
realmId=O4ZR9N2V6U, clientId=
http://192.168.99.100:8888/saml-sp/saml/metadata, userId=null,
ipAddress=192.168.99.1, error=in
valid_user_credentials, auth_method=saml, redirect_uri=
http://192.168.99.100:8888/saml-sp/saml/SSO,
code_id=fa04e6ff-3767-419c-a5bf-7bc2c94e8300
I am a bit lost here on what is wrong. Does this request I pasted above
look correct? If not, let me know what is wrong/missing there. Also, my
understanding is that I don't need to enable anything on keycloak for this.
I was earlier able to do browser based authentication using this same saml
SP, IDP and the user. Then, I enabled ECP on SP to test authentication
using ecp.sh script but I encountered the above error and output. I would
appreciate any help or pointers on this.
Also, for reference, this is the SP response (I printed the $sp_resp
variable in ecp.sh):
<?xml version="1.0" encoding="UTF-8"?>
<soap11:Envelope xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
<soap11:Header>
<paos:Request xmlns:paos="urn:liberty:paos:2003-08" responseConsumerURL="
http://192.168.99.100:8888/saml-sp/saml/SSO"
service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" soap11:actor="
http://schemas.xmlsoap.org/soap/actor/next" soap11:mustUnderstand="1"/>
<ecp:Request xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"
IsPassive="false" soap11:actor="http://schemas.xmlsoap.org/soap/actor/next"
soap11:mustUnderstand="1">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
</ecp:Request>
</soap11:Header>
<soap11:Body>
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://192.168.99.100:8888/saml-sp/saml/SSO"
ForceAuthn="false" ID="a1bj9ed5f38c4c1f1331hifbg36363" IsPassive="false"
IssueInstant="2016-12-24T01:14:48.538Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#a1bj9ed5f38c4c1f1331hifbg36363">
<ds:Transforms>
<ds:Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>sOgymsP3qFQ4QQFiGP7oUjtutUw=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ZGxJgqOcGe2XarIF1JtfjikRmpsIjglB4mKeYdfUbwUavtH25XgZ/YmgTDFlCYbq2piAM0NvibcyPtXjgX26zATtWJg3URqHpqWclccql8I5arrVfkHTKUQxIx0Rk9bxxytsS012SptubO9F4a+b4LAWoaE9L4IymGVtLpZRLYRL2rhhjwIehT/hSXTWWNRWrLWYb03klaCp/1hZIEUIUW1nyeveyWfaeN1LF7BJ63yMdWOrtUEaF388chUcg1dpFB7HeYq1Q5GCYyEsFk3yi1CEcZ/qeXyfbHAwixFOG0pPNyeunn6QDZzFD8sSVepXzuFLb8MuuthNYSb0hVLrwQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDUjCCAjqgAwIBAgIEUOLIQTANBgkqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UE
CBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEM
MAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEy
ODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kx
GDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E
5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13
F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7K
qxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pON
UUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg
0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL
82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A
8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBu
RogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEW
bHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/GuHE=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml2p:AuthnRequest>
</soap11:Body>
</soap11:Envelope>
6 years, 8 months
What code in Keycloak IDP is responsible to return the configuration to Java adapters?
by Michael Furman
Dear Keycloak people,
I need our help.
What code in Keycloak IDP is responsible to return the configuration to Java adapters (Spring Security Adapter) ?
I mean all URLs in the org.keycloak.adapters.KeycloakDeployment class (authServerBaseUrl, tokenUrl etc.).
I have modified org.keycloak.protocol.oidc.OIDCWellKnownProvider but this code is not executed during OIDC protocol with java adapters.
Thanks in advance for your help,
Michael
6 years, 8 months
First use of initial passwords MUST be within configurable timeframe
by Shaikh Asrafali Anwarali
Hi,
Currently we are exploring keycloak for our IAMS requirement "First use of initial or temporary passwords MUST be within configurable timeframe of receipt".
We explore through keycloak but did not find such functionality , could you let us know is such functionality does exist or it can be configured.
To elaborate more on requirement.
When user is created we assign Temporary password for activating account , user uses temporary password to login into keyclaok and at first attempt update for password is asked wherein user needs to changes his/her credential.
This use of temporary password, we want to put constraint like it should be used, say in a day or else account cannot be activated.
Regards,
Asraf Shaikh
6 years, 8 months
SpringSecurity adapter best practices
by Dekel Aslan
Greetings,
We were wondering what is the best practice for the use of spring security adapter:
I notice that the security context is an instance of RefreshableKeycloakSecurityContext, which means (correct me if I'm wrong) that whenever a token is about to revoke, a refresh is issued.
I used all xml beans that's in the documentation<https://keycloak.gitbooks.io/securing-client-applications-guide/content/v...>, but still, when I put a breakpoint on RefreshableKeycloakSecurityContext -> refreshExpiredToken, it stops only once - on logout (which is another mystery to me). I also noticed that this method is public yet no other class uses it.
Do I need to invoke it explicitly? Where?
Thanks,
Dekel.
The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.
6 years, 9 months
External request to REST endpoint return 403 code
by Gustavo Alvarez
Cordial greetings.
I have a configuration of a client of type confidential and with
authorization through role policy. This configuration works correctly in
local, when I do the deployment to access from the public network, despite
having all the same, I only get answers with code 403.
Thanks for your help.
6 years, 9 months
Recommendation for the choice of RDBMS with keycloak
by abhishek raghav
Hi,
We’re looking into databases to use with Keycloak. We have been using
Mongo, but Keycloak has indicated they might drop support for that. Does
anyone keycloak or somebody who is using RDBMS have a strong or weak
recommendation between Postgres, MySQL, and SQL Server?
Keycloak seems to have good support for Postgres and MySQL, while also
supporting SQL Server. Does it matter which one to choose and if yes in
what manner.
We might be dealing with users between 2k to 5k in a multitenant
environment.
Let me know the thoughts on that.
Thanks
Abhishek
6 years, 9 months
Master updated to 2.5.1.Final-SNAPSHOT
by Stian Thorgersen
Master is now ready for bug fixes to be included in 2.5.1.Final.
We're not accepting anything beyond bug fixes into master until 2.5.1.Final
is released! After that we'll get started on 3.0.0.CR1.
6 years, 9 months
Keycloak adapter wildfly EAR
by Jordan Conner
Using keycloak-wildfly-adapter-dist-2.4.0.Final and Wildfly 9.0.2.Final
I am having the same issue as KEYCLOAK-3186
<https://issues.jboss.org/browse/KEYCLOAK-3186>
However, I do not receive an "Invalid User" error, the protected method in
the EJB via @RolesAllowed is ignored (no errors.)
I have the same structure. I use the keycloak-offline-adapter installer,
and the security domain is created in standalone.xml file.
EAR
WAR - contains keycloak.json and security constraints to certain urls in
web.xml with certain roles (WORKING.)
EJB - In my @Stateless beans I've tried @SecurityDomain("keycloak") and
I've tried setting it in jboss-ejb3.xml. I then use @RolesAllowed("admin")
on a single method, this is ignored when invoking that method as a "user"
role.
If I try this same thing in a @Stateless bean inside my WAR it works.
His solution was to convert EAR package to WAR. I would really like to
stick to EAR->EJB-WAR structure.
Thanks,
Jordan
6 years, 9 months
