9:19 a.m.
This is what an application configuration file looks like:
{
"realm" : "demo",
"resource" : "product-portal",
"realm-public-key" : "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADC",
"auth-url" :
"http://localhost:8080/auth-server/rest/realms/demo/tokens/login",
"code-url" :
"http://localhost:8080/auth-server/rest/realms/demo/tokens/access/codes",
"ssl-not-required" : true,
"credentials" : {
"password" : "password"
}
}
Notice that the credentials are in clear text. Admins will dislike this
tremendously. What I propose is that you must obtain the application
configuration file from the admin console. The configuration file would
be encrypted using a hash of a password specific to the application.
THe config file would then look something like this:
{
"realm" : "demo",
"encryptedConfig" : "MIGMA0GCSqGS..."
}
Then, your server instance must be booted up via a system property or
environment variable, i.e.:
standalone.sh -Dkeycloak.myrealm.password=geheim
The keycloak plugin would then decrypt the application config file based
on this password.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:29 a.m.
Can you not just remove the password from the config file completely - and pass the
password directly using the system property?
Another related thing, this only works for server-side applications/services - for
client-side applications the application credentials aren't available (if they are an
attacker can access them by simply downloading the application). To my understanding this
means we need to support the implicit flow for client-side applications?
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Friday, 20 September, 2013 3:19:13 PM
Subject: [keycloak-dev] application configuration idea
This is what an application configuration file looks like:
{
"realm" : "demo",
"resource" : "product-portal",
"realm-public-key" : "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADC",
"auth-url" :
"http://localhost:8080/auth-server/rest/realms/demo/tokens/login",
"code-url" :
"http://localhost:8080/auth-server/rest/realms/demo/tokens/access/codes",
"ssl-not-required" : true,
"credentials" : {
"password" : "password"
}
}
Notice that the credentials are in clear text. Admins will dislike this
tremendously. What I propose is that you must obtain the application
configuration file from the admin console. The configuration file would
be encrypted using a hash of a password specific to the application.
THe config file would then look something like this:
{
"realm" : "demo",
"encryptedConfig" : "MIGMA0GCSqGS..."
}
Then, your server instance must be booted up via a system property or
environment variable, i.e.:
standalone.sh -Dkeycloak.myrealm.password=geheim
The keycloak plugin would then decrypt the application config file based
on this password.
--
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
9:48 a.m.
On 9/20/2013 10:29 AM, Stian Thorgersen wrote:
Can you not just remove the password from the config file completely
- and pass the password directly using the system property?
Config might also include:
* TOTP Key
* Key pair and cert for two-way SSL.
Another related thing, this only works for server-side
applications/services - for client-side applications the application credentials
aren't available (if they are an attacker can access them by simply downloading the
application). To my understanding this means we need to support the implicit flow for
client-side applications?
Depends how the mobile native app wants to do authentication.
Application credentials help prevent spoofing attacks. i.e. making the
user think they are logging into Bank of America or something when
you're really logging into the attacker's site. Auth server requires
client to authenticate before turning a access code into an access
token. Mobile is different because the relationship between user and
application is 1 to 1. I'm not sure what to do for native mobile apps.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:04 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 20 September, 2013 3:48:05 PM
Subject: Re: [keycloak-dev] application configuration idea
On 9/20/2013 10:29 AM, Stian Thorgersen wrote:
> Can you not just remove the password from the config file completely - and
> pass the password directly using the system property?
>
Config might also include:
* TOTP Key
* Key pair and cert for two-way SSL.
Forgot that - with that in mind then encryption + password is a good approach - would be
good if it could be enabled/disabled for a realm though
> Another related thing, this only works for server-side
> applications/services - for client-side applications the application
> credentials aren't available (if they are an attacker can access them by
> simply downloading the application). To my understanding this means we
> need to support the implicit flow for client-side applications?
>
Depends how the mobile native app wants to do authentication.
Application credentials help prevent spoofing attacks. i.e. making the
user think they are logging into Bank of America or something when
you're really logging into the attacker's site. Auth server requires
client to authenticate before turning a access code into an access
token. Mobile is different because the relationship between user and
application is 1 to 1. I'm not sure what to do for native mobile apps.
I guess if application doesn't have access to anything that's not public it's
there's no security implications of the key/secrets to it being leaked. So with that
in mind you could still use the full flow for both html5 and mobile (and any other
client-side stuff, consoles, desktop apps, etc..)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:05 a.m.
Maybe there could be an option on the application to mark it as client-side, then any
applications that are marked as client-side would never be granted any oauth permissions?
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 20 September, 2013 4:04:36 PM
Subject: Re: [keycloak-dev] application configuration idea
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Friday, 20 September, 2013 3:48:05 PM
> Subject: Re: [keycloak-dev] application configuration idea
>
>
>
> On 9/20/2013 10:29 AM, Stian Thorgersen wrote:
> > Can you not just remove the password from the config file completely -
> > and
> > pass the password directly using the system property?
> >
>
> Config might also include:
>
> * TOTP Key
> * Key pair and cert for two-way SSL.
Forgot that - with that in mind then encryption + password is a good approach
- would be good if it could be enabled/disabled for a realm though
>
>
> > Another related thing, this only works for server-side
> > applications/services - for client-side applications the application
> > credentials aren't available (if they are an attacker can access them by
> > simply downloading the application). To my understanding this means we
> > need to support the implicit flow for client-side applications?
> >
>
> Depends how the mobile native app wants to do authentication.
> Application credentials help prevent spoofing attacks. i.e. making the
> user think they are logging into Bank of America or something when
> you're really logging into the attacker's site. Auth server requires
> client to authenticate before turning a access code into an access
> token. Mobile is different because the relationship between user and
> application is 1 to 1. I'm not sure what to do for native mobile apps.
I guess if application doesn't have access to anything that's not public
it's
there's no security implications of the key/secrets to it being leaked. So
with that in mind you could still use the full flow for both html5 and
mobile (and any other client-side stuff, consoles, desktop apps, etc..)
>
> --
> 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
11:47 a.m.
In some docs that I read recently the proposed best practice is that app
is granted only with minimal user registration permission - like Stian
proposed. Then once the user is created it is his identity used for
everything when accessing APIs. Then there is no issue with app code
leakage as it doesn't allow attacker to do anything with the api.
On 09/20/2013 05:05 PM, Stian Thorgersen wrote:
Maybe there could be an option on the application to mark it as
client-side, then any applications that are marked as client-side
would never be granted any oauth permissions?
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com> To: "Bill
Burke"
> <bburke(a)redhat.com> Cc: keycloak-dev(a)lists.jboss.org Sent: Friday,
> 20 September, 2013 4:04:36 PM Subject: Re: [keycloak-dev]
> application configuration idea
>
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com> To: "Stian
Thorgersen"
>> <stian(a)redhat.com> Cc: keycloak-dev(a)lists.jboss.org Sent: Friday,
>> 20 September, 2013 3:48:05 PM Subject: Re: [keycloak-dev]
>> application configuration idea
>>
>>
>>
>> On 9/20/2013 10:29 AM, Stian Thorgersen wrote:
>>> Can you not just remove the password from the config file
>>> completely - and pass the password directly using the system
>>> property?
>>>
>>
>> Config might also include:
>>
>> * TOTP Key * Key pair and cert for two-way SSL.
>
> Forgot that - with that in mind then encryption + password is a
> good approach - would be good if it could be enabled/disabled for a
> realm though
>
>>
>>
>>> Another related thing, this only works for server-side
>>> applications/services - for client-side applications the
>>> application credentials aren't available (if they are an
>>> attacker can access them by simply downloading the
>>> application). To my understanding this means we need to support
>>> the implicit flow for client-side applications?
>>>
>>
>> Depends how the mobile native app wants to do authentication.
>> Application credentials help prevent spoofing attacks. i.e.
>> making the user think they are logging into Bank of America or
>> something when you're really logging into the attacker's site.
>> Auth server requires client to authenticate before turning a
>> access code into an access token. Mobile is different because
>> the relationship between user and application is 1 to 1. I'm not
>> sure what to do for native mobile apps.
>
> I guess if application doesn't have access to anything that's not
> public it's there's no security implications of the key/secrets to
> it being leaked. So with that in mind you could still use the full
> flow for both html5 and mobile (and any other client-side stuff,
> consoles, desktop apps, etc..)
>
>>
>> -- 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
--
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead
noon
We have this option already. Its called Scopes. You assign a scope to
an OAuth Client. The scope is a set of roles the oauth client is
allowed to ask for when logging in a user. So, a mobile native app
could just have a limited scope and public credentials.
Maybe what could be done is after the OAuth Grant Page, the mobile
client would be given a token that allows it to register itself and
create unique credentials with the admin server.
On 9/20/2013 11:05 AM, Stian Thorgersen wrote:
Maybe there could be an option on the application to mark it as
client-side, then any applications that are marked as client-side would never be granted
any oauth permissions?
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Friday, 20 September, 2013 4:04:36 PM
> Subject: Re: [keycloak-dev] application configuration idea
>
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, 20 September, 2013 3:48:05 PM
>> Subject: Re: [keycloak-dev] application configuration idea
>>
>>
>>
>> On 9/20/2013 10:29 AM, Stian Thorgersen wrote:
>>> Can you not just remove the password from the config file completely -
>>> and
>>> pass the password directly using the system property?
>>>
>>
>> Config might also include:
>>
>> * TOTP Key
>> * Key pair and cert for two-way SSL.
>
> Forgot that - with that in mind then encryption + password is a good approach
> - would be good if it could be enabled/disabled for a realm though
>
>>
>>
>>> Another related thing, this only works for server-side
>>> applications/services - for client-side applications the application
>>> credentials aren't available (if they are an attacker can access them by
>>> simply downloading the application). To my understanding this means we
>>> need to support the implicit flow for client-side applications?
>>>
>>
>> Depends how the mobile native app wants to do authentication.
>> Application credentials help prevent spoofing attacks. i.e. making the
>> user think they are logging into Bank of America or something when
>> you're really logging into the attacker's site. Auth server requires
>> client to authenticate before turning a access code into an access
>> token. Mobile is different because the relationship between user and
>> application is 1 to 1. I'm not sure what to do for native mobile apps.
>
> I guess if application doesn't have access to anything that's not public
it's
> there's no security implications of the key/secrets to it being leaked. So
> with that in mind you could still use the full flow for both html5 and
> mobile (and any other client-side stuff, consoles, desktop apps, etc..)
>
>>
>> --
>> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4116
days inactive
4116
days old
6 comments
3 participants
participants (3)
-
Bill Burke -
Bolesław Dawidowicz -
Stian Thorgersen