Users can now specify a Icon Url to be rendered on the login page when social or any other
identity provider is configured. So we just load the image the url entered by the user.
Are you saying that users should change the theme or customize css if they only want to
change an icon for a provider ?
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, December 2, 2014 9:42:15 AM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
All look and feel related things including images and stylesheets should be part of
themes. This is to allow customizing them in the theme. Also, an image is not the correct
way to render a button, it should be defined in CSS.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 2 December, 2014 12:34:45 PM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
You shouldn't have icon images for social providers. They should be specified
as part of the theme in CSS as is now.
----- Original Message -----
> From: "Pedro Igor Silva" <psilva(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 2 December, 2014 12:22:21 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>
> Hi,
>
> Anyone know where I can get the icons images for social providers ? It
> seems zocial defines them encoded in some way in CSS. I need that to
> provide default images if user does not specify their own.
>
> Or is still possible to use zocial ones ?
>
> Regards.
>
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Thursday, November 27, 2014 9:01:38 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>
> Hi guys,
>
> I've done some initial work covering both persistence and brokering. No
> UI, yet. I'm focused on the model, rest api and brokering functionality
> for now.
>
> What I have is enough to decide if we are aligned about this
> functionality. So you can understand how the model (and persistence),
> rest api and brokering functionality looks like. Can we schedule a
> meeting ?
>
> Btw, my branch is here [1].
>
> [1]
https://github.com/pedroigor/keycloak/tree/authentication-broker2
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Thursday, November 20, 2014 2:48:49 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>
> Currently adapters can only make authz decisions (@RolesAllowed) based
> on either realm roles or the roles of one specific application. This is
> related to 1) too.
>
> On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote:
> > 1) Sounds like something definitely worth aiming for.
> >
> > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> >> I just wanted to quickly list the additional work we discussed so
> >> everyone
> >> can think about it (in no particular order):
> >>
> >> 1) Mapping of tokens - how do we deal with mapping of an external token
> >> to
> >> a KC token? For example an external token with attribute 'group'
that
> >> contains 'sales' and 'manager' could be mapped to
'manager' role for
> >> 'sales app in a KC token. Could we use Drools? This could also be used
> >> in
> >> user federation to allow more complex mapping of roles/groups than a
> >> simple 1-1
> >> 2) Retrieving tokens - if an application wants to retrieve the external
> >> token (for example to view Facebook friends if user logged in with
> >> Facebook)
> >> 3) Configure scope - currently for social we only request a very limited
> >> scope (basic profile and email), to for example view Facebook friends
> >> we'd need to ask for that as well
> >> 4) Selecting provider - currently in social (and for first pass of
> >> brokering) we have an icon user has to select, but can we select the
> >> provider in a different way (for example ask user for email, and select
> >> based on email domain)
> >> 5) Gateway - don't create a KC token, but just forward the external
> >> token
> >>
> >> IMO 1) is a killer feature, as it would allow companies to add external
> >> users without having to modify their applications. Issue with 5) is that
> >> applications need to understand more than one token, which would require
> >> rewriting applications.
> >>
> >> This work is also somewhat related to other authentication mechanisms
> >> (for
> >> example Kerberos ticket, LDAP and passwordless).
> >>
> >> ----- Original Message -----
> >>> From: "Pedro Igor Silva" <psilva(a)redhat.com>
> >>> To: "Bill Burke" <bburke(a)redhat.com>
> >>> Cc: keycloak-dev(a)lists.jboss.org
> >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>> Broker
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke(a)redhat.com>
> >>>> To: keycloak-dev(a)lists.jboss.org
> >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>> Broker
> >>>>
> >>>>
> >>>>
> >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Would like to start a discussion about how to enable KC
as an
> >>>>> Authentication Broker in order to supported Chained
Federation
> >>>>> and
> >>>>> also Identity Federation. First of all, some background
about
> >>>>> what
> >>>>> this is all about.
> >>>>>
> >>>>> Currently KeyCloak provides two basic types of
authentication
> >>>>> (correct
> >>>>> me if I'm wrong, please):
> >>>>>
> >>>>> 1) Local authentication (based on some credential
type
> >>>>> enabled
> >>>>> to
> >>>>> a realm)
> >>>>> 2) Social authentication
> >>>>>
> >>>>> Local authentication is about authenticating the user
locally
> >>>>> using
> >>>>> KC's own identity store. Nothing special here. And
Social
> >>>>> Authentication which allows users to choose the Social
IdP
> >>>>> they
> >>>>> want
> >>>>> to authenticate with. In this case, the IdP is always
one of
> >>>>> the
> >>>>> built-in social providers supported by KC such as
Facebook,
> >>>>> Google,
> >>>>> Twitter, Github and so forth.
> >>>>>
> >>>>> When doing social, the user is automatically provisioned
in KC
> >>>>> identity store after a successful authentication. The
user
> >>>>> does
> >>>>> not
> >>>>> need to fill a registration form and can access the
> >>>>> application
> >>>>> very
> >>>>> quickly. During the provisioning some basic information
is
> >>>>> retrieved
> >>>>> from the social provider such as email, firstname and
so
> >>>>> forth.
> >>>>> These
> >>>>> are very basic information, any other information such
as
> >>>>> those
> >>>>> related with authorization policies - eg.: roles and
groups -
> >>>>> must
> >>>>> be
> >>>>> defined later via KC's admin console.
> >>>>>
> >>>>> Another important characteristic of social
authentication is
> >>>>> that
> >>>>> the
> >>>>> application receives a KC token and not the token that
was
> >>>>> issued by
> >>>>> the social IdP during the authentication process. If
the
> >>>>> application
> >>>>> wants to consume resources from the resource provider he
was
> >>>>> authenticated it must obtain the access token(again) by
itself
> >>>>> prior
> >>>>> to invoke the resource provider API. Assuming all those
social
> >>>>> providers are based on oAuth 1.0 or 2.0.
> >>>>>
> >>>>> That said, the Authentication Broker functionality aims
to
> >>>>> cover
> >>>>> the
> >>>>> same use cases but with a lot of more flexibility on how
you
> >>>>> setup
> >>>>> identity providers(not only social ones) and the
different
> >>>>> federation
> >>>>> protocols they may support such as SAML, OpenID, oAuth
and so
> >>>>> forth.
> >>>>> This is useful when an enterprise is providing services
to
> >>>>> different
> >>>>> customers(IdP) and does not want to manage many to many
> >>>>> relationships. When using a broker, the authentication
steps
> >>>>> are
> >>>>> pretty much the same when you are using social
authentication,
> >>>>> with
> >>>>> important differences on how you support different
identity
> >>>>> providers, different federation protocols, how users
are
> >>>>> provisioned
> >>>>> and how claims and attributes are resolved.
> >>>>>
> >>>>> The brokering functionality can be done in two ways
depending
> >>>>> if
> >>>>> the
> >>>>> broker service is acting as a gateway or not. When
acting as a
> >>>>> gateway, the broker will respond to the application the
same
> >>>>> token
> >>>>> issued by the trusted identity provider. For instance,
if the
> >>>>> user
> >>>>> selects a SAML IdP to authenticate with, the application
will
> >>>>> receive
> >>>>> a SAML Response. In this case, the application must also
be
> >>>>> prepared
> >>>>> to handle a specific federation protocol.
> >>>>>
> >>>>> However, the broker service can also be used to
completely
> >>>>> abstract
> >>>>> from the application the protocol used to authenticate
an
> >>>>> user.
> >>>>> In
> >>>>> this case, the application will just receive an ordinary
KC
> >>>>> token
> >>>>> after a successful authentication.
> >>>>>
> >>>>> In both cases, the broker acts as an intermediary where
> >>>>> specific
> >>>>> security policies can be applied when users try to
> >>>>> authenticate
> >>>>> themselves against a 3rd party IdP. That brings a lot of
value
> >>>>> when
> >>>>> you think about auditing, authorization and how users
are
> >>>>> provisioned
> >>>>> when federation of identities is needed. This also
allows
> >>>>> existing
> >>>>> security infrastructures (eg.: SAML-based
infrastructures) to
> >>>>> benefit
> >>>>> from KC's support for cloud, rest and mobile use
cases.
> >>>>>
> >>>>> I think this is enough to start a discussion. I've
an initial
> >>>>> discussion with Stian about all that and we agreed that
> >>>>> abstract
> >>>>> the
> >>>>> protocol from applications should be prioritized. The
main
> >>>>> reason is
> >>>>> that it makes life easier for applications so they only
need
> >>>>> to
> >>>>> know
> >>>>> about KC tokens and nothing else. However that brings
some new
> >>>>> requirements around user provisioning and
claim/attribute
> >>>>> resolution
> >>>>> or mapping. But that would be another thread.
> >>>>>
> >>>>
> >>>> Can you elaborate on "abstract the protocol from
applications"? Not
> >>>> sure what you mean by that. IDP federation should be configured
at
> >>>> the
> >>>> realm level and really has nothing to do with applications.
> >>>>
> >>>> I'm really happy that somebody is doing this. We're
getting a real
> >>>> impressive feature set!
> >>>
> >>> Sure. What I meant was that the application only knows about KC tokens
> >>> nothing else. It will always receive a KC token regardless the
protocol
> >>> used
> >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> >>> whatever).
> >>> The
> >>> example I gave was about an user trying to authenticate against a SAML
> >>> IdP.
> >>> In this case, after a successful authentication on the IdP, the IdP
> >>> will
> >>> issue a token to KC. Then KC will validate the token, perform trust
and
> >>> security checks, do user provisioning and attribute/claim resolution
to
> >>> finally issue a KC token and redirect the user to the application. If
> >>> the
> >>> app is configured to use openid in KC then it will receive a openid
> >>> token
> >>> from KC, not saml ...
> >>>
> >>> The other scenario is pretty much the same. The difference is that KC
> >>> will
> >>> not issue its own token but just replay the token issued by the 3rd
> >>> party
> >>> IdP to the service provider.
> >>>
> >>> I agree that this config goes at the realm level. For instance, to
> >>> create
> >>> and
> >>> enable providers for being used. However, I think we would need some
> >>> specific configuration for applications as well. Specially when
> >>> defining
> >>> default roles, mapping attributes. Another example of application
> >>> config
> >>> is
> >>> when using a OIDC/oAuth IdP. You may want to define scopes
> >>> per-application.
> >>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>>
http://bill.burkecentral.com
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev(a)lists.jboss.org
> >>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev(a)lists.jboss.org
> >>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev