Ask Your Question

Revision history [back]

I don't understand your question. Clients can validate the token themselves or ask keystone to validate it.

GET v3/auth/tokens -- Can be used by the clients to validate the token, GET v2/0/tokens -- Can be used by the clients to validate the token.

(i.e) The call you mentioned is v3 call and v2 has an equivalent call. So nothing new in v3 as for as token validation is concerned

Keystone has 2 types of token. They are UUID and PKI. This is applicable both for v2 and v3

PKI is cert based and it can be verified in the clients using certs. PKI tokens can also be send to keystone via GET v3/auth/tokens or GET v2.0/token to validate

UDDI token can only be validated by sending it to keystone. Keystone default token type is PKI

I don't understand your question. Clients can validate the token themselves or ask keystone to validate it.

GET v3/auth/tokens  -- Can be used by the clients to validate the token,
GET v2/0/tokens      --  Can be used by the clients to validate the token.

token.

(i.e) The call you mentioned is v3 call and v2 has an equivalent call. So nothing new in v3 as for as token validation is concerned

Keystone has 2 types of token. They are UUID and PKI. This is applicable both for v2 and v3

PKI is cert based and it can be verified in the clients using certs. PKI tokens can also be send to keystone via GET v3/auth/tokens or GET v2.0/token to validate

UDDI token can only be validated by sending it to keystone. Keystone default token type is PKI

I don't understand your question. Clients can validate the token themselves or ask keystone to validate it.

GET v3/auth/tokens  -- Can be used by the clients to validate the token,
GET v2/0/tokens      --  Can be used by the clients to validate the token.

(i.e) The call you mentioned is v3 call and v2 has an equivalent call. So nothing new in v3 as for as token validation is concerned

Keystone has 2 types of token. They are UUID and PKI. This is applicable both for v2 and v3

PKI is cert based and it can be verified in the clients using certs. PKI tokens can also be send to keystone via GET v3/auth/tokens or GET v2.0/token to validate

UDDI token can only be validated by sending it to keystone. Keystone default token type is PKI

Update 1:

You are correct about cert apis. It looks odd to call that using V2.0 path. Most probably they will migrate it to v3. There is no logic involved there. As far as I know only keystone middleware is using that apis and it is easy to migrate. Even keystonemiddleware fetches it only once and dumps them under signing dir. So if you manually copy those files, then you are fine

I don't understand your question. Clients can validate the token themselves or ask keystone to validate it.

GET v3/auth/tokens  -- Can be used by the clients to validate the token,
GET v2/0/tokens v2.0/tokens      --  Can be used by the clients to validate the token.

(i.e) The call you mentioned is v3 call and v2 has an equivalent call. So nothing new in v3 as for as token validation is concerned

Keystone has 2 types of token. They are UUID and PKI. This is applicable both for v2 and v3

PKI is cert based and it can be verified in the clients using certs. PKI tokens can also be send to keystone via GET v3/auth/tokens or GET v2.0/token to validate

UDDI token can only be validated by sending it to keystone. Keystone default token type is PKI

Update 1:

You are correct about cert apis. It looks odd to call that using V2.0 path. Most probably they will migrate it to v3. There is no logic involved there. As far as I know only keystone middleware is using that apis and it is easy to migrate. Even keystonemiddleware fetches it only once and dumps them under signing dir. So if you manually copy those files, then you are fine

I don't understand your question. Clients can validate the token themselves or ask keystone to validate it.

GET v3/auth/tokens  -- Can be used by the clients to validate the token,
GET v2.0/tokens      --  Can be used by the clients to validate the token.
token
curl -i  -H "X-Auth-Token: <token of="" person="" who="" is="" validating"="" -h="" "x-subject-token:="" "token="" to="" be="" validated"="" http:="" identity-host:35357="" v3="" auth="" token="" get="" v2.0="" tokens="" --="" can="" be="" used="" by="" the="" clients="" to="" validate="" the="" token.="" curl="" -i="" -h="" "x-auth-token:="" <token="" of="" person="" who="" is="" validating"="" http:="" identity-host:35357="" v2.0="" tokens<"token="" to="" be="" validated"="">

(i.e) The call you mentioned is v3 call and v2 has an equivalent call. So nothing new in v3 as for as token validation is concerned

Keystone has 2 types of token. They are UUID and PKI. This is applicable both for v2 and v3

PKI is cert based and it can be verified in the clients using certs. PKI tokens can also be send to keystone via GET v3/auth/tokens or GET v2.0/token to validate

UDDI token can only be validated by sending it to keystone. Keystone default token type is PKI

Update 1:

You are correct about cert apis. It looks odd to call that using V2.0 path. Most probably they will migrate it to v3. There is no logic involved there. As far as I know only keystone middleware is using that apis and it is easy to migrate. Even keystonemiddleware fetches it only once and dumps them under signing dir. So if you manually copy those files, then you are fine

I don't understand your question. Clients can validate the token themselves or ask keystone to validate it.

GET v3/auth/tokens  -- Can be used by the clients to validate the token
curl -i  -H "X-Auth-Token: <token of="" person="" who="" is="" validating"="" -h="" "x-subject-token:="" "token="" to="" be="" validated"="" http:="" identity-host:35357="" v3="" auth="" token="" get="" v2.0="" tokens="" --="" can="" be="" used="" by="" the="" clients="" to="" validate="" the="" token.="" curl="" -i="" -h="" "x-auth-token:="" <token="" of="" person="" who="" is="" validating"="" http:="" identity-host:35357="" v2.0="" tokens<"token="" to="" be="" validated"="">
Token of person who is validating"  -H "X-Subject-Token: "Token To be validated"  http://identity-host:35357/v3/auth/token

GET v2.0/tokens      --  Can be used by the clients to validate the token.

curl -i  -H "X-Auth-Token: Token of person who is validating"     http://identity-host:35357/v2.0/tokens<"Token To be validated">

(i.e) The call you mentioned is v3 call and v2 has an equivalent call. So nothing new in v3 as for as token validation is concerned

Keystone has 2 types of token. They are UUID and PKI. This is applicable both for v2 and v3

PKI is cert based and it can be verified in the clients using certs. PKI tokens can also be send to keystone via GET v3/auth/tokens or GET v2.0/token to validate

UDDI token can only be validated by sending it to keystone. Keystone default token type is PKI

Update 1:

You are correct about cert apis. It looks odd to call that using V2.0 path. Most probably they will migrate it to v3. There is no logic involved there. As far as I know only keystone middleware is using that apis and it is easy to migrate. Even keystonemiddleware fetches it only once and dumps them under signing dir. So if you manually copy those files, then you are fine

I don't understand your question. Clients can validate the token themselves or ask keystone to validate it.

GET v3/auth/tokens  -- Can be used by the clients to validate the token
curl -i  -H "X-Auth-Token: Token of person who is validating"  -H "X-Subject-Token: "Token To be validated"  http://identity-host:35357/v3/auth/token

GET v2.0/tokens      --  Can be used by the clients to validate the token.

curl -i  -H "X-Auth-Token: Token of person who is validating"     http://identity-host:35357/v2.0/tokens<"Token http://identity-host:35357/v2.0/tokens/<"Token To be validated">

(i.e) The call you mentioned is v3 call and v2 has an equivalent call. So nothing new in v3 as for as token validation is concerned

Keystone has 2 types of token. They are UUID and PKI. This is applicable both for v2 and v3

PKI is cert based and it can be verified in the clients using certs. PKI tokens can also be send to keystone via GET v3/auth/tokens or GET v2.0/token to validate

UDDI token can only be validated by sending it to keystone. Keystone default token type is PKI

Update 1:

You are correct about cert apis. It looks odd to call that using V2.0 path. Most probably they will migrate it to v3. There is no logic involved there. As far as I know only keystone middleware is using that apis and it is easy to migrate. Even keystonemiddleware fetches it only once and dumps them under signing dir. So if you manually copy those files, then you are fine

I don't understand your question. Clients can validate the token themselves or ask keystone to validate it.

GET v3/auth/tokens  -- Can be used by the clients to validate the token
curl -i  -H "X-Auth-Token: Token of person who is validating"  -H "X-Subject-Token: "Token To be validated"  http://identity-host:35357/v3/auth/token

GET v2.0/tokens      --  Can be used by the clients to validate the token.

curl -i  -H "X-Auth-Token: Token of person who is validating"     http://identity-host:35357/v2.0/tokens/<"Token To be validated">

(i.e) The call you mentioned is v3 call and v2 has an equivalent call. So nothing new in v3 as for as token validation is concerned

Keystone has 2 types of token. They are UUID and PKI. This is applicable both for v2 and v3

PKI is cert based and it can be verified in the clients using certs. PKI tokens can also be send to keystone via GET v3/auth/tokens or GET v2.0/token to validate

UDDI token can only be validated by sending it to keystone. Keystone default token type is PKI

Update 1:

You are correct about cert apis. It looks odd to call that using V2.0 path. Most probably they will migrate it to v3. There is no logic involved there. As far as I know only keystone middleware is using that apis and it is easy to migrate. Even keystonemiddleware fetches it only once and dumps them under signing dir. So if you manually copy those files, then you are fine

Update 2:

Actually keystone has those cert apis in v3. It is under different root

https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-simple-certs-ext.md