Am Thu, Dec 04, 2025 at 06:42:48PM +0100 schrieb Timo Eisenmann:
> On Tue, 2025-12-02 at 18:02 +0100, Sumit Bose via sssd-devel wrote:
> > Am Tue, Dec 02, 2025 at 04:53:18PM +0100 schrieb Timo Eisenmann via
> > sssd-devel:
> > > Hello,
> > >
> > > I am currently looking into sssd-idp for authentication with
> > > Keycloak.
> > > And that works fine, but I would be interested in accessing the
> > > tokens
> > > (access, refresh, id) after logging in.
> > > AFAICS, those are neither passed through by PAM with forward_pass,
> > > nor
> > > is there any sssctl subcommand to do this.
> > >
> > > Is there some way to do this currently, or if not, is this planned
> > > in
> > > some way?
> >
> > Hi,
> >
> > yes, this is planned, but I was busy with other tasks recently.
> >
> > The idea is to let oidc_child return them to the backend after success
> > authentication so that they can be stored together with the other user
> > data in the cache.
> >
>
> Mind if I take a shot at it?
> I would store them in some new attrs {access,id,refresh}Token under the
> user.
Hi,
not at all, feel free to provide a patch.
>
> > The next question would be how to make the best use of it. I was
> > thinking about a utility which can put them in the profiles of typical
> > web browsers in the user's home directory so that they are available for
> > the user without having to authenticate a second time in the browsers.
> >
>
> That would be my use case too.
>
> But instead of a utility specifically for provisioning a certain set of
> browsers, I would take a more generic approach.
> That is, a utility that just extracts the tokens from the cache.
> The browser-specific provisioning with the tokens could then be done by
> more specialized utilities/scripts.
> An option to refresh the token might also be convenient.
>
> E.g. something along the lines of:
> sss_token --refresh --get-access-token user@keycloak
> would refresh the tokens, then return the access_token.
Hi,
that sounds nice but there might be some access/permission issues. Only
the user itself should be allowed to read/refresh his tokens but users
cannot access the cache directly.
Currently we have the DBus based InfoPipe interface to request general
data about a user, but here we do not check which user is allowed to
read which information.
We plan to add a varlink based userdb interface in the near future which
already has the concept of "privileged" attributes which should be only
accessible for the user or root. This seems to me the most elegant way
to read the token.
About refreshing, you might know that SSSD already can refresh Kerberos
tickets e.g. with the help of an internal task in the krb5 provider. I
was thinking about a similar mechanism if there is a refresh token
available in the idp provider. This way there would be always a valid
access token as long as the refresh token allows it and no additional
interaction is needed.
bye,
Sumit
>
> > HTH
> >
> > bye,
> > Sumit
> >
> > >
> > > Regards,
> > > Timo
> >
> >
> >
> > > --
> > > _______________________________________________
> > > sssd-devel mailing list -- [email protected]
> > > To unsubscribe send an email to
> > > [email protected]
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedorahosted.org/archives/list/[email protected]
> > > Do not reply to spam, report it:
> > > https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
sssd-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
