CONTROLLING ACCESS

• US 20130219473A1
• Filed: 02/22/2013
• Published: 08/22/2013
• Est. Priority Date: 02/22/2012
• Status: Active Grant

• Current Assignee: Nokia Solutions and Networks US LLC (Nokia Corporation)
• Original Assignee: Nokia Solutions and Networks US LLC (Nokia Corporation)
• Inventors: SCHAEFER, Manfred
• Granted Patent: US 9,135,415 B2
• Time in Patent Office: Days
• US Class Current: 726/4
• CPC Class Codes: G06F 21/31 User authentication
• CPC Class Codes: G06F 21/335 for accessing specific resources, e.g. using Kerberos tickets
• CPC Class Codes: G06F 2221/2137 Time limited access, e.g. to a computer or data
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/083 using passwords cryptographic mechanisms or cryptographic arrangements for entity authentication using a predetermined code H04L9/3226
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources

Abstract

To provide access to an account in an apparatus in response to a request to the account, the apparatus creates and forwards a challenge for this request and waits for a token signed by a centralized signing entity for the account, the token comprising access enabling data. When such a token is received, the apparatus validates the token, and only if the validation succeeds, enables access to the account.

Claims

1. A method comprising:

receiving in an apparatus an access request to an account in the apparatus;

creating, in response to the access request, a challenge;

forwarding the challenge;

receiving a signed token relating to the challenge;

checking whether or not the token is signed by a centralized entity that is verifiable by the apparatus and authorized to provide signing services for the account;

if the token is signed by the centralized entity, checking whether a first response in the token corresponds to a response the apparatus expects to receive for the challenge; and

if yes, checking whether the access enabling data indicates that a further input from a user is required or the token is an access token itself;

if the token is an access token itself, granting the access;

if the further input is required;

prompting the user for credentials;

receiving credentials via a user interface;

checking whether the received credentials correspond to credentials in the access enabling data;

if yes, granting the access to the account.

2. A method as claimed in claim 1, further comprising:

maintaining certificate information in the apparatus;

receiving in the token one or more certificates;

checking, prior to checking whether the access enabling data indicates that a further input from a user is required or the token is an access token itself, the validity of the received one or more certificates using the certificate information; and

checking whether the access enabling data indicates that a further input from a user is required or the token is an access token itself if the one or more certificates are valid, the token is signed by the centralized entity and the first response corresponds to the response the apparatus is waiting for.

3. A method as claimed in claim 1, further comprising:

receiving in the access enabling data one or more credentials with one or more use conditions for the credentials;

monitoring the fulfillment of the one or more use conditions;

considering a credential as valid if all use conditions relating to the credentials are fulfilled; and

granting the access to the account only if the credentials received via the user interface correspond to valid credentials in the access enabling data.

4. A method as claimed in claim 3, wherein

the one or more credentials comprises a password, a list of passwords, a hash of a password, or hashes of passwords, and

the one or more use conditions defines at least one of a common or credential-specific validity time for the one or more credentials, and a common or credential-specific use-time-value indicating how many times the one or more credentials can be used to obtain access to the account.

5. A method as claimed in claim 3, further comprising:

checking, in response to the access request and prior to creating the challenge, whether there are any valid credentials for the account;

if there are, prompting a user to input a credentials instead of creating the challenge.

6. A method as claimed in claim 1, further comprising:

determining whether or not the account provides rights to change maintenance related information or other configuration parameters of the apparatus; and

creating the challenge only in response to the account providing the rights to change the maintenance related information or other configuration parameters of the apparatus.

17. A computer program product comprising program instructions adapted to perform any of the steps of a method as claimed in claim 1 when the computer program is run.

18. An apparatus, comprising:

at least one processor; and

at least one memory including computer program code,

the at least one memory and computer program code configured to, with the at least one processor, cause the apparatus to perform the method of claim 1.

7. A method comprising:

authenticating and authorizing by a first apparatus a user for an account allowing access to a signing service request service;

receiving a challenge;

authenticating and authorizing the first apparatus with a centralized entity providing signing services;

establishing a secured communication channel between the first apparatus and the centralized entity;

forming a signing request including at least the challenge;

sending the signing request to the centralized entity over the channel;

receiving in the first apparatus a signed token from the centralized entity, the signed token comprising at least access enabling data for another account in a second apparatus; and

forwarding the signed token to the second apparatus.

8. A method as claimed in claim 7, further comprising:

outputting at least part of the access enabling data to the user.

9. A method as claimed in claim 7, the method further comprising:

providing local signing service;

requesting temporary certificates for the local signing service from the centralized entity;

receiving the temporary certificates;

monitoring validity of the temporary certificates;

forming, in response to detecting that establishment of the channel fails, a local token using the temporary certificates;

signing the local token;

forwarding the signed local token as the local token to the second apparatus.

10. A method as claimed in claim 9, further comprising:

providing the local signing service only to a predefined group of accounts and/or second apparatuses;

receiving, with the challenge, information on the predefined group of accounts and/or the second apparatuses;

checking, in response to detecting that establishment of the channel fails and before forming the local token, whether or not the account and/or the second apparatus belongs to the predefined group of accounts and/or second apparatuses; and

forming the local token if the account and/or the second apparatus belongs to the predefined group of accounts and/or second apparatuses.

11. A method comprising:

providing a centralized entity for signing services;

authenticating and authorizing, by the centralized entity, a first apparatus;

establishing a secure communication channel between the first apparatus and the centralized entity;

receiving in the centralized entity from the first apparatus a signing request containing a challenge, the signing request indicating that it is for obtaining access enabling data to an account in a second apparatus;

generating by the centralized entity access enabling data;

calculating by the centralized entity a response to the challenge;

forming by the centralized entity a token comprising at least the access enabling data and the challenge;

signing by the centralized entity the token; and

sending the signed token over the secure communication channel to the first apparatus.

12. A method as claimed in claim 11, further comprising:

obtaining local policy relating to the second apparatus and/or the account;

generating one or more use conditions according to the local policy, the one or more use conditions comprising at least one of validity period of the access enabling data and information on how many times the access enabling data or a piece of the access enabling data can be used to obtain access to the account in the second apparatus;

adding to the token the one or more use conditions before the token is signed.

13. A method as claimed in claim 12, wherein the access enabling data comprises one or more credentials, and the one or more use conditions defines a validity time for the one or more credentials and/or a use-time-value indicating how many times the one or more credentials can be used to obtain access to the account, the validity time and/or the use-time-value being common or credential-specific.

14. A method as claimed in claim 11, further comprising:

adding certificate information shared with the second apparatus to the token.

15. A method as claimed in claim 11, further comprising:

receiving in the centralized signing entity from the first apparatus a request for one or more temporary certificates by means of which the first apparatus may form and sign a token comprising the access enabling data to the account in the second apparatus; and

issuing one or more temporary certificates to the first apparatus.

16. A method as claimed in claim 15, further comprising:

maintaining in the centralized signing entity information indicating allowed apparatuses to which the centralized signing entity is allowed to issue temporary certificates; and

issuing the one or more temporary certificate, if the first apparatus belongs to the allowed apparatuses.

19. A system, comprising:

a first apparatus, including a first processor;

a first memory, including first computer code, the at least one memory and first computer code configured to, with the at least one processor, cause the first apparatus to receive an access request to an account in the first apparatus;

create, in response to the access request, a challenge;

forward the challenge;

receive a signed token relating to the challenge;

check whether or not the token is signed by a centralized entity that is verifiable by the apparatus and authorized to provide signing services for the account;

if the token is signed by the centralized entity, check whether a first response in the token corresponds to a response the apparatus expects to receive for the challenge; and

if yes, check whether the access enabling data indicates that a further input from a user is required or the token is an access token itself;

if the token is an access token itself, grant the access;

if the further input is required;

prompt the user for credentials;

receive credentials via a user interface;

check whether the received credentials correspond to credentials in the access enabling data;

if yes, granting the access to the account;

said system further comprising a second apparatus, said second apparatus including;

a second processor;

a second memory including second computer program code, said second memory and second computer program code configured to with the second processor, cause the second apparatus to authenticate and authorize by the first apparatus a user for an account allowing access to a signing service request service;

receive a challenge;

authenticate and authorize the first apparatus with a centralized entity providing signing services;

establish a secured communication channel between the first apparatus and the centralized entity;

form a signing request including at least the challenge;

send the signing request to the centralized entity over the channel;

receive in the first apparatus a signed token from the centralized entity, the signed token comprising at least access enabling data for another account in a second apparatus; and

forward the signed token to the second apparatus, said system further comprising;

a third apparatus, said third apparatus including a third processor;

a third memory including third computer program code, said third memory and third computer program code configured to, with the third processor, cause the third apparatus to

provide a centralized entity for signing services;

authenticate and authorize, by the centralized entity, the first apparatus;

establish a secure communication channel between the first apparatus and the centralized entity;

receive in the centralized entity from the first apparatus a signing request containing a challenge, the signing request indicating that it is for obtaining access enabling data to an account in the second apparatus;

generate by the centralized entity access enabling data;

calculate by the centralized entity a response to the challenge;

form by the centralized entity a token comprising at least the access enabling data and the challenge;

sign by the centralized entity the token; and

send the signed token over the secure communication channel to the first apparatus, said system further comprising

a fourth apparatus, said fourth apparatus including a root certificate issuance service, the fourth apparatus being configured to provide the third apparatus with information needed for signing tokens;

wherein the second apparatus is connectable at least to the third apparatus, the third apparatus is connectable to the second apparatus and to the fourth apparatus, and the first apparatus is not directly connectable to the third and fourth apparatus.

20. A system as claimed in claim 19, wherein information exchange between the first apparatus and the second apparatus is over a network connection and/or over a Bluetooth connection and/or utilizes user interfaces in the first and the second apparatus and/or the user interfaces and portable memory means.

21. A system as claimed in claim 19, wherein the signed token provides n times access to the account, wherein n is an integer whose value is one or more.