How to store value in RequiredAction so it becomes available in an Authenticator?
by Rashmi Singh
Hi,
When I set a value in UserSessionNote in authenticator as:
context.getClientSession().setUserSessionNote("testname", "testvalue");
the value set is available in other authenticators. However, I have a
changePasswordAction where I need to store a value to be made available to
an authenticator. I tried setting in a similar way but the value is not
available in the auhenticator. Is that the expected behavior?
In that case, how can I store a value in my ChangePasswordAction so I can
retrieve it in an Authenticator? Any help will be appreciated.
8 years, 2 months
Keycloak: NameID/BaseID/EncryptedID from SAML REQUEST is not adding to client session
by rony joy
We have a requirement to receive Username/EmailId in the Subject/NameID
field of SAML Request. Keycloak then receive that value in a custom
authenticator
and send it to the tokenvalidator for further flow. The idea here is
to omit the step to ask user name from user again if that is present
in the SAMLRequest.
1. In Keycloak I don't see NameID/BaseID/EncryptedId value from the
SAML request is putting in the client session. why?
2. I can see that keycloak is parsing the Subject/Name ID field, but
not adding to the client session? Is the any reason for this?
3. I am willing to fork the repo and do the changes.
4. Please see our SAML request
Please let me know your suggestions and ideas
Rony Joy
<?xml version="1.0" encoding="UTF-8"?><saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="http://192.168.99.100:9980/auth/realms/saml-demo/protocol/saml"
ForceAuthn="false" ID="daakemmdhjmfajnhpljnckldjmcejllkffegibdj"
IsPassive="false" IssueInstant="2016-10-04T04:42:32.860Z"
Version="2.0"><saml2:Issuer
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://localhost:8080/employee-sig-idfirst/</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="#daakemmdhjmfajnhpljnckldjmcejllkffegibdj"><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>R4HTkFdDm5tYqRLGb1Wh8QUwa0o=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>IokRvOo8z3EES+85HvckmYYXQ/Q8DadiGHJdZmmYGpQ3VZW1MYnlBgeVwc5Dx4wsNGvRPpAsNM7ij9qGhgLUORuqZshb4YFMMqqDTzg4SoHuq2Ol7jdXo3x39hyZGKjoiC7qBxXbSml7j9UixL/7CescKvuh1xTSOBulsM4EefaY+J7Ud8ZSEMaqfCk36OaWZwq+8Ss/aZ6p31oMKu9T2dGTW7DZY3mn4Fz0aVr3lYzkaJAOQ+mMHOK8TDYlmZcc1e9l37KuKR3Z9dBawXdplHHD25vW/C0NnNfxbo90UTgN2kpDlhGSjrxW3XpvqEpEaF3DwR9Q40iD3M0+su6ZXg==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIC5TCCAc0CBgFWTDcTwDANBgkqhkiG9w0BAQsFADA2MTQwMgYDVQQDDCtodHRwOi8vbG9jYWxo
b3N0OjgwODAvZW1wbG95ZWUtc2lnLWlkZmlyc3QvMB4XDTE2MDgwMjE3MDMxM1oXDTI2MDgwMjE3
MDQ1M1owNjE0MDIGA1UEAwwraHR0cDovL2xvY2FsaG9zdDo4MDgwL2VtcGxveWVlLXNpZy1pZGZp
cnN0LzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9BGbuxabZxnZdlT8UwWZmT4537
zduU08apai2E3m3/xJNEKU5gcufLlYXzAoHNGvoX1j+GowKjv+Z0uypJLpFoyE9tj+ng15sO5QfE
EK5L7K0yl3W3s4AeNue6YTQjeuL0DoFVj2hUcMEZpd7gjLp/aVzk/9Rx53kIJpEOt9Y1RHql+vW2
hIeq9Qap2qkOzjPN85257hqCylfhfk7z7xgMDA6EUalU+QCMecsqEr2FDfUtE1qHPAJTMHmjK8DC
4PjtnkLroPSaUoJ1YxJtCcw1vzOrDbSsMW2J6GBtkzNMkRIJIZCqCus4C9MtAVE8hlgSAZSzwN6S
FVIj/pgYAscCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAKtrEjO1MWXxQGx6dD4Ogw9fcJfjXVlY0
lsis1s7hxeaqYHZSAtNWTkFp7JltaPp6VFmBs7hPSJUvPo7z13rP+0KuoEht+VgiFlceWFNUN5ur
tYskQoN+sQ1V8Z6u/vku6fwVOQm9YpS7Nn582A2nBL4IdgCMYhpPPfN39yV24yWpv4VTrOG1q3pj
yc1IHCU+ooP8pa64gXt0T/HRRCnm+CWgwYSrhdYYG0rYxAdKQ5GhkfRhR2rx2kOgHIuxZ4e2kVla
x9zQ9fuBtDn6u4VdzoikJUiEYxt4Sb4YfvgchU1Sk4G0Y+K2oP5dPMemdsZMWqzzvrSNQrebPgsB
KYpXxA==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>*<saml2:Subject
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"><saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID></saml2:Subject>*<saml2p:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/></saml2p:AuthnRequest>
8 years, 2 months
new synchronization SPI
by Bill Burke
Marek in particular...
Why do we have 2 sync methods currently?
syncAllUsers syncChangedUsers
Could we just have one method?
sync(KeycloakSessionFactory sessionFactory, String realmId, ComponentModel model, DatelastSync);
8 years, 2 months
Using Client's Attributes in Custom Policy
by Erik Berdonces Bonelo
Hello,
I’m trying to implement a custom policy but I’m having a hard time with the Evaluation API.
As I see, there is just some few available settings to get, but, I’m trying to fetch specifically a custom attribute of the client, let’s say FOO, which can be set through adding them in the representation when registering a new Client, which we will call BAR, through the Registration API. Is it even possible?
Otherwise, I’m not sure in which case would the client attributes be used.
In the settings of the client BAR, in policies, in the test tab, there is in the ‘Contextual Attributes' part, a ‘Custom Attribute’ option. Is there any possible to set them, or to use them?
I’ve been trying to link them somehow to FOO attribute using a custom scripted policy in Javascript for the client BAR such as:
contextAttributes.containsValue(‘kc.client.attributes.FOO', ‘myFooAttributeValue')
But I’m not successful, plus it’s really difficult to debug so :(
Any advice on how to implement something like this? I’m just trying to create a policy, where one of the parameters is loaded from the client, and I want to save that property somewhere accessible such as a custom attribute, and not so hardcoded such as a javascript or Drool script.
Thanks a lot!
—
Best regards,
Erik Berdonces Bonelo
8 years, 2 months
new provider deployer working on branch!
by Bill Burke
I've implemented a Keycloak provider deployer and it works great. I
re-implemented the JPA User Storage SPI example. The provider is now a
@Stateful EJB and EntityManager access is all managed by
@PersistenceContext. The example now looks really simple and elegant
rather than the crap I mentioned before. Would not have worked without
the JTA integration I did (see previous email). Things left to do:
* hot deployment. Pretty sure I can implement this
* Make sure things work in WARs and EARs.
* Also thinking of defining a @KeycloakProvider annotation that you can
use on your ProviderFactories. This would remove the need to specify a
META-INF/services file and the annotation could be scanned for at
deployment. Would work like this:
@KeycloakProvider(UserStorageProviderFactory.class)
public class MyProvider ... {
}
As a side note, one thing I could look into is the ability to use
@Inject of a KeycloakSession. Developer could then write entire web
applications that are deployed separately and worked with the keycloak
API directly. @Inject KeycloakSession would work similarly to
@PersistenceContexts EntityManager. KeycloakSessions would be
associated with a transaction. This will give us nice integration with
Java EE and give a lot of power to developers wanting to extend keycloak.
8 years, 2 months
Sending Username/emailid in the saml req as NameID
by rony joy
Hi All,
We have a requirement to send Username/EmailId in the Subject/NameID field
to the keycloak. Keycloak then receive that value in a custom authenticator
and send it to the tokenvalidator for further flow. The idea here is to
omit the step to ask user name from user again.
1. In Keycloak I am not able to see NameID value since keycloak is not
putting this in the client session. why?
2. I can see that keycloak is parsing the Subject/Name ID field. How can I
get this value in my custom Autheticator ?
3. Please see our SAML request
Please let me know your suggestions and ideas
Rony Joy
<?xml version="1.0" encoding="UTF-8"?><saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="
http://192.168.99.100:9980/auth/realms/saml-demo/protocol/saml"
ForceAuthn="false" ID="daakemmdhjmfajnhpljnckldjmcejllkffegibdj"
IsPassive="false" IssueInstant="2016-10-04T04:42:32.860Z"
Version="2.0"><saml2:Issuer
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://localhost:8080/employee-sig-idfirst/</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="#daakemmdhjmfajnhpljnckldjmcejllkffegibdj"><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>R4HTkFdDm5tYqRLGb1Wh8QUwa0o=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>IokRvOo8z3EES+85HvckmYYXQ/Q8DadiGHJdZmmYGpQ3VZW1MYnlBgeVwc5Dx4wsNGvRPpAsNM7ij9qGhgLUORuqZshb4YFMMqqDTzg4SoHuq2Ol7jdXo3x39hyZGKjoiC7qBxXbSml7j9UixL/7CescKvuh1xTSOBulsM4EefaY+J7Ud8ZSEMaqfCk36OaWZwq+8Ss/aZ6p31oMKu9T2dGTW7DZY3mn4Fz0aVr3lYzkaJAOQ+mMHOK8TDYlmZcc1e9l37KuKR3Z9dBawXdplHHD25vW/C0NnNfxbo90UTgN2kpDlhGSjrxW3XpvqEpEaF3DwR9Q40iD3M0+su6ZXg==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIC5TCCAc0CBgFWTDcTwDANBgkqhkiG9w0BAQsFADA2MTQwMgYDVQQDDCtodHRwOi8vbG9jYWxo
b3N0OjgwODAvZW1wbG95ZWUtc2lnLWlkZmlyc3QvMB4XDTE2MDgwMjE3MDMxM1oXDTI2MDgwMjE3
MDQ1M1owNjE0MDIGA1UEAwwraHR0cDovL2xvY2FsaG9zdDo4MDgwL2VtcGxveWVlLXNpZy1pZGZp
cnN0LzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9BGbuxabZxnZdlT8UwWZmT4537
zduU08apai2E3m3/xJNEKU5gcufLlYXzAoHNGvoX1j+GowKjv+Z0uypJLpFoyE9tj+ng15sO5QfE
EK5L7K0yl3W3s4AeNue6YTQjeuL0DoFVj2hUcMEZpd7gjLp/aVzk/9Rx53kIJpEOt9Y1RHql+vW2
hIeq9Qap2qkOzjPN85257hqCylfhfk7z7xgMDA6EUalU+QCMecsqEr2FDfUtE1qHPAJTMHmjK8DC
4PjtnkLroPSaUoJ1YxJtCcw1vzOrDbSsMW2J6GBtkzNMkRIJIZCqCus4C9MtAVE8hlgSAZSzwN6S
FVIj/pgYAscCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAKtrEjO1MWXxQGx6dD4Ogw9fcJfjXVlY0
lsis1s7hxeaqYHZSAtNWTkFp7JltaPp6VFmBs7hPSJUvPo7z13rP+0KuoEht+VgiFlceWFNUN5ur
tYskQoN+sQ1V8Z6u/vku6fwVOQm9YpS7Nn582A2nBL4IdgCMYhpPPfN39yV24yWpv4VTrOG1q3pj
yc1IHCU+ooP8pa64gXt0T/HRRCnm+CWgwYSrhdYYG0rYxAdKQ5GhkfRhR2rx2kOgHIuxZ4e2kVla
x9zQ9fuBtDn6u4VdzoikJUiEYxt4Sb4YfvgchU1Sk4G0Y+K2oP5dPMemdsZMWqzzvrSNQrebPgsB
KYpXxA==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>*<saml2:Subject
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"><saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID></saml2:Subject>*<saml2p:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/></saml2p:AuthnRequest>
8 years, 2 months
Configurable cookie names
by Martin Hardselius
What are your thoughts on configurable cookie names (or other visible
references to Keycloak)? I.e a way to override e.g "KEYCLOAK_SESSION" with
"MYCOMPANY_SESSION". The use case being
1. Product branding
2. Making it harder to figure out exactly which technology that's used
behind the scenes
Regards,
Martin
8 years, 2 months
Added rotation of public keys of external clients and identity providers
by Marek Posolda
OIDC dynamic profile needs to support ability to rotate public keys of
external clients.
In order to this, I've added PublicKeyStorageProvider, which is used to
store external public keys of the OIDC clients (those clients, which
require authentication by signed JWT) and OIDC identity providers (those
which require signature verification). There is just one implementation
of the SPI based on local infinispan cache to cache computed public keys.
The advantages are:
- Improved performance : Previously during client authentication with
signed JWT (or during verification of token signed by OIDC
identityProvider), the public keys were always computed from PEM. This
didn't have very great performance. Now we have local infinispan cache,
so the public keys are cached locally. The cache is set with eviction
and expiration, so the locally cached keys are expired from cache in
case of inactive / deleted clients.
- Ability to dynamically download the keys if token signed by unknown
"kid" (Key ID) is found : Previously we supported that public key (or
certificate) PEM of particular client was always hardcoded in Keycloak
database. This is still supported, so everything is backwards
compatible. However we additionally support that client or identity
provider can have "jwks_url" defined. In that case, public keys are
always downloaded dynamically from the given jwks_url when token signed
by unknown "kid" is found. In other words, always when external client
(or idp) rotate it's keys, Keycloak will dynamically download them and
update the storage.
There is configurable limit (10 seconds by default), so that client
won't try to download keys from "jwks_url" more than once in 10 seconds.
This is to avoid DOS, so when evil sends many requests with unknown
"kid", the keycloak won't try to download keys from "jwks_url" for every
request.
Marek
8 years, 2 months
