[JBoss JIRA] (JBIDE-22756) Connection: varioius weirdness in token/password
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22756?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22756:
-------------------------------------
Description:
The lifecycle of the token is rather weird and needs a consistent logic:
When connecting via wizard the token is set in the connection wizard:
{code:title=ConnectionWizardPageModel#connect}
...
try {
IConnection connection = createConnection(connectionFactory, connectionAuthenticationProvider);
...
{code}
{code:title=ConnectionWizardPageModel#createConnection}
...
if (authProvider != null) {
authProvider.update(connection); // sets the token
}
...
{code}
{code:title=BearTokenAuthenticationProvider#update}
...
connection.setAuthScheme(IAuthorizationContext.AUTHSCHEME_OAUTH);
connection.setToken(tokenObservable.getValue());
connection.setRememberToken(rememberTokenObservable.getValue());
...
{code}
{code:title=Connection#connect}
if(authorize()) {
...
{code}
{code:title=Connection#authorized}
...
if (context.isAuthorized()) {
String username = context.getUser().getName();
String token = context.getToken();
updateAuthorized(username, token);
} else {
...
{code}
The token is then fetched from client and set to the connection
{code:title=Connection#updateAuthorized}
setToken(token);
...
{code}
and the password is cleared
{code:Connectoin#savePasswordOrToken}
} else if (IAuthorizationContext.AUTHSCHEME_OAUTH.equals(getAuthScheme())){
boolean success = saveOrClear(SECURE_STORAGE_TOKEN_KEY, this.token, isRememberToken());
if(success) {
//Avoid second secure storage prompt.
//Token is stored, password should be cleared.
clearPassword();
{code}
I suspect the aim here is to clear existing password in secure storage if the user is switching password->token based auth (and vice versa)
The opposite is then not fully congruent. The token is only cleared in secure storage, not in Connection instance var
{code:title=Connection#savePasswordOrToken}
if (IAuthorizationContext.AUTHSCHEME_BASIC.equals(getAuthScheme())) {
boolean success = saveOrClear(SECURE_STORAGE_PASSWORD_KEY, this.password, isRememberPassword());
if (success) {
//Avoid second secure storage prompt.
// Password is stored, token should be cleared.
clearToken();
}
{code:Connection#clearToken}
// dont clear the token instance var: JBIDE-22594
setRememberToken(false);
saveOrClear(SECURE_STORAGE_TOKEN_KEY, null, false);
{code}
I suspect that we should only clear in secure storage, not in the Connection instance as we see in JBIDE-22594 (for the opposite case where we dont clear the token in the Connection instance). But then one has to keep in mind that all auth is token based. Even if you auth via password initially, the auth is then switched to token based once the authorization succeeded and we got a token:
{code:title=Connection#updateAuthorized}
setToken(token);
if (IAuthorizationContext.AUTHSCHEME_OAUTH.equalsIgnoreCase(getAuthScheme())) {
setUsername(username);
}
// force auth strategy to token if authorized
TokenAuthorizationStrategy tokenStrategy = new TokenAuthorizationStrategy(token, username);
client.setAuthorizationStrategy(tokenStrategy);
{code}
Another issue is that the connection and the auth schemeare both stored in different classes. The connection is stored via
{code:title=ConnectionPersistency#persist}
preferences.saveConnections(connections.keySet().toArray(new String[] {}));
...
{code}
while the auth scheme is stored in Connection#saveAuthSchemePreference:
{code:title=Connection#connect}
saveAuthSchemePreference();
{code}
was:
The lifecycle of the token is rather weird and needs a consistent logic:
When connecting via wizard the token is set in the connection wizard:
{code:title=ConnectionWizardPageModel#connect}
...
try {
IConnection connection = createConnection(connectionFactory, connectionAuthenticationProvider);
...
{code}
{code:title=ConnectionWizardPageModel#createConnection}
...
if (authProvider != null) {
authProvider.update(connection); // sets the token
}
...
{code}
{code:title=BearTokenAuthenticationProvider#update}
...
connection.setAuthScheme(IAuthorizationContext.AUTHSCHEME_OAUTH);
connection.setToken(tokenObservable.getValue());
connection.setRememberToken(rememberTokenObservable.getValue());
...
{code}
{code:title=Connection#connect}
if(authorize()) {
...
{code}
{code:title=Connection#authorized}
...
if (context.isAuthorized()) {
String username = context.getUser().getName();
String token = context.getToken();
updateAuthorized(username, token);
} else {
...
{code}
The token is then fetched from client and set to the connection
{code:title=Connection#updateAuthorized}
setToken(token);
...
{code}
and the password is cleared
{code:Connectoin#savePasswordOrToken}
} else if (IAuthorizationContext.AUTHSCHEME_OAUTH.equals(getAuthScheme())){
boolean success = saveOrClear(SECURE_STORAGE_TOKEN_KEY, this.token, isRememberToken());
if(success) {
//Avoid second secure storage prompt.
//Token is stored, password should be cleared.
clearPassword();
{code}
I suspect the aim here is to clear existing password in secure storage if the user is switching password->token based auth (and vice versa)
The opposite is then not fully congruent. The token is only cleared in secure storage, not in Connection instance var
{code:title=Connection#savePasswordOrToken}
if (IAuthorizationContext.AUTHSCHEME_BASIC.equals(getAuthScheme())) {
boolean success = saveOrClear(SECURE_STORAGE_PASSWORD_KEY, this.password, isRememberPassword());
if (success) {
//Avoid second secure storage prompt.
// Password is stored, token should be cleared.
clearToken();
}
{code:Connection#clearToken}
// dont clear the token instance var: JBIDE-22594
setRememberToken(false);
saveOrClear(SECURE_STORAGE_TOKEN_KEY, null, false);
{code}
I suspect that we should only clear in secure storage, not in the Connection instance as we see in JBIDE-22594 (for the opposite case where we dont clear the token in the Connection instance). But then one has to keep in mind that all auth is token based. Even if you auth via password initially, the auth is then switched to token based once the authorization succeeded and we got a token:
{code:title=Connection#updateAuthorized}
setToken(token);
if (IAuthorizationContext.AUTHSCHEME_OAUTH.equalsIgnoreCase(getAuthScheme())) {
setUsername(username);
}
// force auth strategy to token if authorized
TokenAuthorizationStrategy tokenStrategy = new TokenAuthorizationStrategy(token, username);
client.setAuthorizationStrategy(tokenStrategy);
{code}
Another issue is that the auth scheme, which determines if we do password or oauth is stored in preferences
{code:title=Connection#connect}
saveAuthSchemePreference();
{code}
while password or token are stored to secure storage. If we're using basic auth, we need a password from secure storage. If we're using oauth we need a token. Both are thus tightly linked while being persisted to different facilities.
> Connection: varioius weirdness in token/password
> -------------------------------------------------
>
> Key: JBIDE-22756
> URL: https://issues.jboss.org/browse/JBIDE-22756
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.4.1.AM2
> Reporter: Andre Dietisheim
>
> The lifecycle of the token is rather weird and needs a consistent logic:
> When connecting via wizard the token is set in the connection wizard:
> {code:title=ConnectionWizardPageModel#connect}
> ...
> try {
> IConnection connection = createConnection(connectionFactory, connectionAuthenticationProvider);
> ...
> {code}
> {code:title=ConnectionWizardPageModel#createConnection}
> ...
> if (authProvider != null) {
> authProvider.update(connection); // sets the token
> }
> ...
> {code}
> {code:title=BearTokenAuthenticationProvider#update}
> ...
> connection.setAuthScheme(IAuthorizationContext.AUTHSCHEME_OAUTH);
> connection.setToken(tokenObservable.getValue());
> connection.setRememberToken(rememberTokenObservable.getValue());
> ...
> {code}
> {code:title=Connection#connect}
> if(authorize()) {
> ...
> {code}
> {code:title=Connection#authorized}
> ...
> if (context.isAuthorized()) {
> String username = context.getUser().getName();
> String token = context.getToken();
> updateAuthorized(username, token);
> } else {
> ...
> {code}
> The token is then fetched from client and set to the connection
> {code:title=Connection#updateAuthorized}
> setToken(token);
> ...
> {code}
> and the password is cleared
> {code:Connectoin#savePasswordOrToken}
> } else if (IAuthorizationContext.AUTHSCHEME_OAUTH.equals(getAuthScheme())){
> boolean success = saveOrClear(SECURE_STORAGE_TOKEN_KEY, this.token, isRememberToken());
> if(success) {
> //Avoid second secure storage prompt.
> //Token is stored, password should be cleared.
> clearPassword();
> {code}
> I suspect the aim here is to clear existing password in secure storage if the user is switching password->token based auth (and vice versa)
> The opposite is then not fully congruent. The token is only cleared in secure storage, not in Connection instance var
> {code:title=Connection#savePasswordOrToken}
> if (IAuthorizationContext.AUTHSCHEME_BASIC.equals(getAuthScheme())) {
> boolean success = saveOrClear(SECURE_STORAGE_PASSWORD_KEY, this.password, isRememberPassword());
> if (success) {
> //Avoid second secure storage prompt.
> // Password is stored, token should be cleared.
> clearToken();
> }
> {code:Connection#clearToken}
> // dont clear the token instance var: JBIDE-22594
> setRememberToken(false);
> saveOrClear(SECURE_STORAGE_TOKEN_KEY, null, false);
> {code}
> I suspect that we should only clear in secure storage, not in the Connection instance as we see in JBIDE-22594 (for the opposite case where we dont clear the token in the Connection instance). But then one has to keep in mind that all auth is token based. Even if you auth via password initially, the auth is then switched to token based once the authorization succeeded and we got a token:
> {code:title=Connection#updateAuthorized}
> setToken(token);
> if (IAuthorizationContext.AUTHSCHEME_OAUTH.equalsIgnoreCase(getAuthScheme())) {
> setUsername(username);
> }
> // force auth strategy to token if authorized
> TokenAuthorizationStrategy tokenStrategy = new TokenAuthorizationStrategy(token, username);
> client.setAuthorizationStrategy(tokenStrategy);
> {code}
> Another issue is that the connection and the auth schemeare both stored in different classes. The connection is stored via
> {code:title=ConnectionPersistency#persist}
> preferences.saveConnections(connections.keySet().toArray(new String[] {}));
> ...
> {code}
> while the auth scheme is stored in Connection#saveAuthSchemePreference:
> {code:title=Connection#connect}
> saveAuthSchemePreference();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22756) Connection: varioius weirdness in token/password
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-22756:
----------------------------------------
Summary: Connection: varioius weirdness in token/password
Key: JBIDE-22756
URL: https://issues.jboss.org/browse/JBIDE-22756
Project: Tools (JBoss Tools)
Issue Type: Task
Components: openshift
Affects Versions: 4.4.1.AM2
Reporter: Andre Dietisheim
The lifecycle of the token is rather weird and needs a consistent logic:
When connecting via wizard the token is set in the connection wizard:
{code:title=ConnectionWizardPageModel#connect}
...
try {
IConnection connection = createConnection(connectionFactory, connectionAuthenticationProvider);
...
{code}
{code:title=ConnectionWizardPageModel#createConnection}
...
if (authProvider != null) {
authProvider.update(connection); // sets the token
}
...
{code}
{code:title=BearTokenAuthenticationProvider#update}
...
connection.setAuthScheme(IAuthorizationContext.AUTHSCHEME_OAUTH);
connection.setToken(tokenObservable.getValue());
connection.setRememberToken(rememberTokenObservable.getValue());
...
{code}
{code:title=Connection#connect}
if(authorize()) {
...
{code}
{code:title=Connection#authorized}
...
if (context.isAuthorized()) {
String username = context.getUser().getName();
String token = context.getToken();
updateAuthorized(username, token);
} else {
...
{code}
The token is then fetched from client and set to the connection
{code:title=Connection#updateAuthorized}
setToken(token);
...
{code}
and the password is cleared
{code:Connectoin#savePasswordOrToken}
} else if (IAuthorizationContext.AUTHSCHEME_OAUTH.equals(getAuthScheme())){
boolean success = saveOrClear(SECURE_STORAGE_TOKEN_KEY, this.token, isRememberToken());
if(success) {
//Avoid second secure storage prompt.
//Token is stored, password should be cleared.
clearPassword();
{code}
I suspect the aim here is to clear existing password in secure storage if the user is switching password->token based auth (and vice versa)
The opposite is then not fully congruent. The token is only cleared in secure storage, not in Connection instance var
{code:title=Connection#savePasswordOrToken}
if (IAuthorizationContext.AUTHSCHEME_BASIC.equals(getAuthScheme())) {
boolean success = saveOrClear(SECURE_STORAGE_PASSWORD_KEY, this.password, isRememberPassword());
if (success) {
//Avoid second secure storage prompt.
// Password is stored, token should be cleared.
clearToken();
}
{code:Connection#clearToken}
// dont clear the token instance var: JBIDE-22594
setRememberToken(false);
saveOrClear(SECURE_STORAGE_TOKEN_KEY, null, false);
{code}
I suspect that we should only clear in secure storage, not in the Connection instance as we see in JBIDE-22594 (for the opposite case where we dont clear the token in the Connection instance). But then one has to keep in mind that all auth is token based. Even if you auth via password initially, the auth is then switched to token based once the authorization succeeded and we got a token:
{code:title=Connection#updateAuthorized}
setToken(token);
if (IAuthorizationContext.AUTHSCHEME_OAUTH.equalsIgnoreCase(getAuthScheme())) {
setUsername(username);
}
// force auth strategy to token if authorized
TokenAuthorizationStrategy tokenStrategy = new TokenAuthorizationStrategy(token, username);
client.setAuthorizationStrategy(tokenStrategy);
{code}
Another issue is that the auth scheme, which determines if we do password or oauth is stored in preferences
{code:title=Connection#connect}
saveAuthSchemePreference();
{code}
while password or token are stored to secure storage. If we're using basic auth, we need a password from secure storage. If we're using oauth we need a token. Both are thus tightly linked while being persisted to different facilities.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22755) Add support for Service catalog
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-22755:
-----------------------------------
Summary: Add support for Service catalog
Key: JBIDE-22755
URL: https://issues.jboss.org/browse/JBIDE-22755
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: openshift
Affects Versions: 4.4.1.AM1
Reporter: Fred Bricon
Kubernetes is introducing the concept of service catalog (https://github.com/kubernetes/kubernetes/pull/17543)
This ticket is meant to discuss the potential impacts on the OpenShift tooling, in other words: do we need to do anything to support service catalogs?
- on the rest client level
- on the UI level (new actions, wizards)
The PR has not been merged upstream yet, so it's obviously too early to discuss implementation details, but at least we planted the seed for future discussions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22754) Add support for Daemon*
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-22754:
-----------------------------------
Summary: Add support for Daemon*
Key: JBIDE-22754
URL: https://issues.jboss.org/browse/JBIDE-22754
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: openshift
Affects Versions: 4.4.1.AM1
Reporter: Fred Bricon
Kubernetes is introducing the concept of DaemonSets (~ Jobs) https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/extensions/...
This ticket is meant to discuss the potential impacts on the OpenShift tooling, in other words: do we need to do anything to support DaemonSets?
- on the rest client level
- on the UI level (new actions, wizards)
We'd need some input from OpenShift savvy people here, [~jcantrill], [~sspeiche]?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22753) Add support for PetSets
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-22753:
-----------------------------------
Summary: Add support for PetSets
Key: JBIDE-22753
URL: https://issues.jboss.org/browse/JBIDE-22753
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: openshift
Affects Versions: 4.4.1.AM1
Reporter: Fred Bricon
A new concept of PetSet is being introduced in Kubernetes 1.3 https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/...
This ticket is meant to discuss the potential impacts on the OpenShift tooling, in other words: do we need to do anything to support PetSets?
- on the rest client level
- on the UI level (new actions, wizards)
We'd need some input from OpenShift savvy people here, [~jcantrill], [~sspeiche]?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months