Add SAML Extensions (and AuthContext) as another client note to the AuthenticationSessionModel in SamlService
by Roland
Hello,
when a SAML Request is received in Keycloak, the method loginRequest in
abstract class BindingProtocol in class
org.keycloak.protocol.samlSamlService puts the information from the request
into the AuthenticationSessionModel in this section of code:
authSession.setProtocol(SamlProtocol.LOGIN_PROTOCOL);
authSession.setRedirectUri(redirect);
authSession.setAction(
AuthenticationSessionModel.Action.AUTHENTICATE.name());
authSession.setClientNote(SamlProtocol.SAML_BINDING,
bindingType);
authSession.setClientNote(GeneralConstants.RELAY_STATE,
relayState);
authSession.setClientNote(SamlProtocol.SAML_REQUEST_ID,
requestAbstractType.getID());
What we are missing here is the SAML Extensions, which happen to be in the
SAML Request which we receive, and which we want to pass on to a brokered
external Identity Provider.
For example something like this:
ExtensionsType et = requestAbstractType.getExtensions();
List<Object> list = et.getAny();
<create some kind of String representation>
authSession.setAuthNote("SAML_EXTENSION", <the String
representation>);
In the same way we would also like access to the AuthContext through the
authSession.
I would offer to contribute this if the community approves the idea.
Thanks and Regards,
Roland
3 years, 8 months
Putting a value into a custom Protocol mapper
by Chris Smith
I'm trying to have a custom protocol mapper provide a serialized Kerberos ticket as a claim
I have updated the KerberosUsernamePasswordAuthenticator so that it gets the ticket
public Subject authenticateSubject(String username, String password) throws LoginException {
String principal = getKerberosPrincipal(username);
logger.debug("Validating password of principal: " + principal);
loginContext = new LoginContext("does-not-matter", null,
createJaasCallbackHandler(principal, password),
createJaasConfiguration());
loginContext.login();
serializedKerberosTicket = serializeTicket();
logger.debug("Principal " + principal + " authenticated succesfully");
return loginContext.getSubject();
}
private String serializeTicket() {
KerberosTicket kerberosTicket = loginContext.getSubject()
.getPrivateCredentials(KerberosTicket.class)
.stream().findFirst().get();
try (ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos)){
oos.writeObject(kerberosTicket);
return Base64.getEncoder().encodeToString(bos.toByteArray());
} catch (IOException e) {
logger.error("Kerberos ticket serialization failed", e);
return null;
}
}
I reviewed the SPNEGOAuthenticator and traced it's execution to see how it adds the Kerberos ticket and I do not see that as a workable approach as it is so different from the Kerberos User/Password authenticator.
Where can my custom KerberosUsernamePasswordAuthenticator put the serialized ticket so that my custom protocol mapper will get it and add it as a claim on my Access token?
I have looked and googled with no luck.
3 years, 9 months
Re: [keycloak-dev] passing SAML extensions and context to custom authenticators
by Caranzo Gideon
Hi Hynek,
Thank you for your response. Yes, I agree with you. It would be good to have this mechanism in those areas as well.
I already have a PR ready for just the SAML login portion. Is it fine with you if I submit this first so that we can use it as early as possible? We can create a separate ticket to implement similar mechanism for other SAML messages and broker endpoint which can be done in near future.
Thanks,
Gideon
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Hynek Mlnarik
Sent: Thursday, January 24, 2019 1:58 AM
To: Gideon Caranzo <gideonray(a)gmail.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] passing SAML extensions and context to custom authenticators
Hi Gideon,
thanks for the idea. Something like that would be a useful enhancement. The implementation would need to cover also the broker endpoint, other SAML message types (extensions are part of message types other than AuthnRequest as well), and count on several implementations of the hypothetical SamlAuthenticationPreprocessor. Could you please file an "Enhancement" JIRA?
--Hynek
On Wed, Jan 16, 2019 at 5:49 PM Gideon Caranzo <gideonray(a)gmail.com> wrote:
> Hi All,
>
> I'd like to propose a feature that allows custom authenticators to
> handle SAML extensions, authentication context and other request attributes.
>
> Right now in OIDC, all request claims are passed to custom
> authenticators which allows for customized behavior depending on the claims.
> However, this is not the case for SAML. Only attributes that are
> explicitly set (e.g. NameID) in the auth session are passed to custom authenticators.
>
> Information like SAML extension and authentication context are not
> available which limits the ability to define custom behaviors. In the
> past, we ran into similar limitation and we had to update keycloak
> core to add support for NameID attribute.
>
> To solve this, we can have an optional hook that pre-process SAML
> login request right before authentication. The hook can then extract
> the needed attributes and set it accordingly for custom authenticators to process.
>
> The pre-processing will be done in
> *SamlService.BindingProtocol.loginRequest()*:
>
> *public* *class* SamlService *extends* AuthorizationEndpointBase {
>
> *. . .*
>
> *public* *abstract* *class* BindingProtocol {
>
> . . .
>
> *protected* Response loginRequest(String relayState,
> AuthnRequestType requestAbstractType, ClientModel client) {
>
> . . .
>
> SamlAuthenticationPreprocessor preProcessor = session
> .getProvider(SamlAuthenticationPreprocessor.*class*);
>
> *if* (preProcessor != *null*) {
>
> preProcessor.process(requestAbstractType, authSession);
>
> }
>
>
>
> *return* newBrowserAuthentication(authSession,
> requestAbstractType.isIsPassive(), redirectToAuthentication);
>
> }
>
>
> Let me know what you think. Thanks.
>
> Best regards,
> Gideon
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> ts.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cgi
> deon.caranzo%40gemalto.com%7C6f947d88676b4f788b2108d681d1d529%7C37d0a9
> db7c464096bfe31add5b495d6d%7C0%7C0%7C636839135555784466&sdata=Yhpx
> 28KFJWJGa1kv1ROWWqJd3nt60YvAb0YmeKUU5Mg%3D&reserved=0
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists....
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
3 years, 9 months
Social login rest api
by Yor Men
Hi,
Does keycloak provide an api that can generate a link for you to click on
and redirect you to let say github and login.
Let me sight an example, we have an application that is secured with
keycloak, we want to allow users to be able to login to the app using
github, facebook and google without having to go to the keycloak page in
any way.
What we want to do is, when the login page is called, the controller
generates the URI and is bound to the model. This model value is placed in
a particular social login button.
Any other suggestion is welcome.
Thank you.
3 years, 11 months
"You are already logged-in" issue
by Vlasta Ramik
Hi,
I'm working on https://issues.jboss.org/browse/KEYCLOAK-5179 See if
message "You are already logged-in" can be avoided during authentication.
In current state we discard the RootAuthenticationSession when user
successfully finishes the authentication. In that moment we loose all
the information stored in AuthenticationSession(s) for other tab(s) and
in some cases we do not know where to redirect the user. To solve this
issue there seems to be 2 possibilities.
1. Do not remove RootAuthenticationSession once the user finishes the
authentication. Instead we can remove just AuthenticationSession
associated with the specific tab from the RootAuthenticationSession and
the RootAuthenticationSession would be deleted together with last
AuthenticationSession from it.
2. Add and pass redirect_uri parameter to login flow. With the parameter
we'd always have an information where it should be redirected in case
the authentication was successfully finished in other tab.
With solution #1 it'd increase the memory as it keeps
RootAuthenticationSession alive till all tabs are alive.
Solution #2 keeps current behavior regarding the authentication sessions
but it slightly increases the length of uris.
wdyt?
3 years, 11 months
[KEYCLOAK-9870] - Gatekeeper renewal does not renew refresh tokens
by Bruno Oliveira
Some time ago we got a bug report for Gatekeeper related with refresh
token revocation[1]. Here are the steps to reproduce:
"In keycloak, menu Tokens, set "revoke refresh token" to ON with value
set to 0. This means refresh token can be used only once.
Gain access with a session through keycloak-gatekeeper, wait token
expiry, try calling a resource: this works. Now wait again for a second
token expiry. try calling a resource: failure - the refresh token has
expired"
>From my perspective, it looks like the expected behavior and not a bug.
If the access token has expired in the first time, the refresh token was
used to obtain a new one and request access to the resource. So in the
second request, failure should be expected.
So it's better to ask. What is the expected behavior when "revoke
refresh token" is set to 0 from the adapters? I tried to look at our docs,
but couldn't find anything.
[1] - https://issues.jboss.org/browse/KEYCLOAK-9870
--
abstractj
3 years, 11 months
Identity first login flow
by Arlen Thurber
Hello Keycloak community,
I am looking for more information on an custom authentication method named
Identity first login flow. I found this concept in a keycloak Jira ticket
https://issues.jboss.org/browse/KEYCLOAK-1514
The issue was opened 03/Jul/15. There was a discussion back in February of
2018 that mentioned that this functionality would be offered "out of the
box", but i cant find any more mention of it, and the issue was just
recently
put into plan on 06/Mar/19 .
In the description of Identity first login flow :
"This makes it possible to not require a password for a user when other
authentication mechanisms are used (for example fingerprint, two-way ssl,
etc.). Also, it allows automatically redirecting to an external IdP when
the user is linked to an external IdP (either the user used the IdP to
login before or a email domain has been configured to the IdP)."
Does anyone have any more information about this concept, an example of it
working, or advice on how this login flow could be achieved? I have started
looking into a custom authenticator and authentication flow, but it would
be ideal if this functionality was built in.
Thank you,
Arlen
<http://www.datastax.com/>
3 years, 11 months
UMA authorization process in Gatekeeper
by maxime.suret＠early-birds.io
Hi All,
When Keycloak Gatekeeper gets a 401 response with a permission ticket
from upstream, it would be very useful if it could fetch the
corresponding RPT and retry accessing the upstream resource with it.
The RPT would then be placed in the access cookie to avoid this process
in subsequent requests.
That would also be a nice feature to have when using gatekeeper as a
forwad signing proxy.
What do you think ? I am willing to implement this myself.
Thanks !
Maxime
--
<https://www.eventbrite.com/e/atelier-by-early-birds-x-saint-gobain-distri...>
3 years, 11 months
