Skip to content

SocIoTal Identity Manager

jbbum edited this page Nov 15, 2016 · 24 revisions

SocIoTal Identity Manager

The Identity Management (IdM) system follows a claim-based approach with Attribute Based Credentials (ABC). The IdM relies on the Idemix cryptographic library from IBM, providing additional means to deal with IoT scenarios where consumers and providers’ can be not only traditional computers, but also smart objects (e.g. smartphones). The IdM endows users and smart objects with means to control and manage their private data in their smartphone, defining partial identities over their whole identity, which is derived from the credential obtained from de Issuer. The usage of partial identities ensures a privacy-preserving solution with minimal disclosure of personal information. Unlike in traditional IdMs, the subject smart object is not redirected to its online Identity Provider (IdP) during the transaction, so that the IdP is not involved when the target device verifies the smart object’s attributes.

SocIoTal IdM has been recently integrated with Fi-Ware Keyrock IdM to support traditional and basic, but necessary, Identity management operations in scenarios where claim-based accesses are not needed. Keyrock IdM provides mechanisms such as secure and private authentication from users to devices, networks and services, authorization & trust management, user profile management, privacy-preserving disposition of personal data, Single Sign-On (SSO) to service domains and Identity Federation towards applications.

The SocIoTal IdM is composed of five main components:

  1. SocIoTal-IdM-Android-Client: It is an android application that allows obtaining Idemix credentials from the Issuer server. It also allows interact with the Verifier server which can validate the partial identity derived from the credential.

  2. SocIoTal-Issuer-Server: It is a web application implemented with Java servlets and XML-RPC which allows generating Idemix credentials for clients. Communications are done by https. The client must be authenticated against the Issuer using a valid certificate. The Issuer also support the verification functionality.

  3. SocIoTal-Verifier-Server: It is a web application, also implemented with Java servlets and XML-RPC, which is able to validate partial identities presented by the client application.

  4. SocIoTal-IdM-Enabled-Capability Manager: The IdM-Enabled-Capability-Manager is a web application that allows users to obtain capability tokens using their partial identities. In other words, it allows authenticating and demonstrating their attributes by means of Idemix proofs of having a valid credential issued by the Issuer.

  5. SocIoTal IdM KeyRock Client: The SocIoTal IdM KeyRock Client Java library provides a basic API for identity management by implementing a client to interact with the FIWARE KeyRock server. To carry out such communication, the SCIM 2.0 and Identity API v3 interfaces provided by this IdM are used.

SocIoTal IdM Android Client

The Android app "SocIoTalIdMAndroidClient.apk" as well as the android library can be found in the SocIoTal repository:

This first proof-of-concept android app provides three main functionalities:

  • Obtain an Idemix credential from the Issuer.
  • Validate a partial identity (Idemix proof) derived from the obtained Idemix credential
  • Obtain a authz capability token from the capability manager using the partial identity

The application requires a proper certificate signed by the CA. The certificate is used to authenticate the user against the Issuer Server. The communication with the Issuer is done by HTTPs. The app already includes a valid certificate for testing purposes. Notice that the Issuer web container (i.e. Apache Tomcat) is configured to trust the certificate signed by the CA.

Following figure shows three screen shoots of the IdM android app

IdM app screeshots

Idemix cryptographic library requires the recipient (the client user) to share the same Idemix system parameters and group parameters with the Issuer Server. These parameters are public and accessible by two configuration files. The android client is already configured to read from these two files to perform the cryptographic operations required in the issuance and proving Idemix operations.

SYSTEM_PARAM_LOCATION = "http://host:port/idemix/files/sp.xml";

GROUP_PARAM_LOCATION = "http://host:port/idemix/files/gp.xml";

The issuer public key location is available at: ISSUER_PUBLIC_KEY_LOCATION = "http://host:port/idemix/files/ipk.xml";

The SocIoTal IdM relies on the Idemix cryptographic library v2.3.0. For further information about Idemix and the library, please, refer to: http://www.zurich.ibm.com/idemix/downloads.html

Client API

Developers can take advantage of the java API to provide to their android applications a way of work with partial identities. The API provides two main classes to deal with the main functionalities. The IdemixManager and the CapabilitiyManger. The IdemixManager class allows dealing with main operations.

IssuanceCredential

It allows obtaining an Idemix credential from the Issuer server. The crendential follows an data model structure given by the first parameter. The attributes values to be included in the credential are passed in the second parameter

Method

BigInteger nonce issuanceCredential(String credStructLocation, Values values)

Parameters

  • credStructLocation: the credential structure
  • values: the attributes values to be included in the credential

Return value

The cryptographic credential from the issuer (a binary file), which is given a common name to be stored in the client side to be employed later on.

Request Credential structure example

VerifyProof

It allows verifying an Idemix cryptographic proof (partial identity) generated by the client based on a credential obtained previouly from the Issuer server. The proof follows an data model structure given by the first parameter Method Boolean verifyProof(String proofSpecification, String credentialName)

Parameters:

  • proofSpecification: the proof specification structure (partial identity) with the attributes to be verified by the Verifier entity
  • credentialName: the credential name among the ones obtained (and stored) previously the client.

Return value Indicates whether the proof is valid or not according to the proof specification and the credential passed as parameters

getCapabilityToken

The CapapabilityManager class provides methods for obtaining a capability token provided the partial identity, i.e. the idemix proof of a particular attributes of an Idemix credential. Method Token getCapabilityToken(String proofSpecification, String credentialName, String resource, String action, String device)

Parameters:

-proofSpecification: the proof specification structure (partial identity) with the attributes to be verified by the Verifier entity

  • credentialName: the credential name among the ones obtained (and stored) previously the client.
  • resource: the resource in the device to which obtain access for
  • action: the action to be done over the device (e.g. get)
  • device: the device to obtain a capability Return value Capability token in Json format

authenticate

The keyrock authentication service is provided by the Issuer entity. Although the authentication end-point is different from the issuer-end-point the address/port are the same. The java client API provides a method for final user to authenticate themselves against the issuer to obtain a keyrock token. It is located in KeyRockManager class.

SocIoTal Server https://plaltform.sociotal.eu:8443/idemix/KeyRockAuthNServlet Method String authenticate (String username, String userpass)

Parameters:

  • userName: the name of the user register in keyrock
  • userPass: the attributes values to be included in the credential

Return value

The barer token Id generated by Keyrock that can be used afterwards as header for SSO.

getEntityAttributes

This method is provided by the client java api and allows obtaining the user attributes stored in keyrock. The user obtaining the entity attributes should have previously authenticated as this method requires an authentication token as parameter.

SocIoTal Server https://plaltform.sociotal.eu:8443/idemix/KeyRockUserServlet Method

String authenticate (String tokenId)

Parameters:

-userName: the name of the user register in keyrock

Return value

The barer token Id generated by Keyrock that can be used afterwards as header for SSO.

Simple usage example in Android:

         /////////////////////////////////////////////////
                // INITIALIZATION
                // Before making any test make sure you have set the proper values in the Constants class.
                // Nonetheless, the API provides default values of the SOCIOTAL deployment for testing purposes
                ////////////////////////////////////////////////////

                //Second parameters tells the IdemixManager that it is being instantiated in library mode
                IdemixManager.initialize(getApplicationContext(), Boolean.TRUE);

                //copy the CA cert from the android raw directory to the sdcard, from where is loaded
                IdemixManager.getInstance().getConfig().copyResourceFileToSdCard(R.raw.ca);

                XMLRPCSecureClient client = new XMLRPCSecureClient(Constants.getISSUER_END_POINT());
                IdemixSecureXMLRPCService idemixService = new IdemixSecureXMLRPCService(client);
                IdemixManager.getInstance().setIdemixService(idemixService);

                Constants.ISSUER_ADDRESS = "xxxxxxxxxxx";
                Constants.ISSUER_PORT = "8443";



                /////////////////////////////////////////////////
                //GET USER ATTRIBUTES FROM KEYROCK.
                // The keyrock authentication service is provided by the Issuer entity. Thus, although the authentication end-point
                // is different from the issuer-end-point the address/port are the same
                // ////////////////////////////////////
                IdemixManager.getInstance().setServiceURL(Constants.getISSUER_AUTHN_SERVICE_END_POINT());
                String tokenId = KeyRockManager.getInstance().authenticate("username", "userpass");
                Map<String, EntityAttribute> attributeMap = KeyRockManager.getInstance().getEntityAttributes(tokenId);




                ////////////////////////////////////
                //GET IDEMIX CREDENTIAL, using all the attributes obtained from Keyrock. Notice that the Issuer will
                // check that attributes included in the requested credential match the attributes in Keyrock
                ////////////////////////////////////////////

                IdemixManager.getInstance().setServiceURL(Constants.getISSUER_END_POINT());
                CredentialManager.initialize(getApplicationContext(), IdemixManager.getInstance().getConfig());
                Values values = CredentialManager.getInstance().getCredentialValues(attributeMap);

                Boolean test = IdemixManager.getInstance().issuanceCredential(Constants.getUSER_CRED_STRUCTURE(), values, "cred_test1a.bin");
                System.out.println("Result from Issuer server: " + test);



                ///////////////////////////////
                // CREATE and VALIDATE a partial identity (i.e. idemix proof), containig all attributes from the credential
                //////////////////////////////
                List<Attribute> attributes = CredentialManager.getInstance().getAttributeList(attributeMap);
                List<Attribute> selectedAttributes =new ArrayList<>();

                for (Attribute a:attributes){ //we are going to create and verify a partial identity, that is going to contain only the "id" attribute among the ones of the credential
                    if (a.getName().equals("id"))
                        selectedAttributes.add(a);
                }

                //creates the idemix proof (i.e. the partial identity)
                String credentialName="usercredential";
                String credentialBinaryFile="cred_test1a.bin";

                ProofSpec proofSpec = IdemixManager.getInstance().createSimpleProof(Constants.getUSER_CRED_STRUCTURE(),credentialName, attributes, selectedAttributes);
                HashMap<String, CommitmentOpening> commitment = CredentialManager.getInstance().getCommitmentOpeningUser(proofSpec, selectedAttributes);

                Constants.VERIFIER_ADDRESS = "XXXXXXXX";
                Constants.VERIFIER_PORT = "8443";
                IdemixManager.getInstance().setServiceURL(Constants.getVERIFIER_END_POINT());

                //verifies the partial identity of having the credential (full credential values verification)
                test = IdemixManager.getInstance().verifyProof(proofSpec, credentialName, credentialBinaryFile,commitment);
                System.out.println("Is valid the credential? " + test);



                ///////////////////////////////
                //Get Capability Token
                ////////////////////////////////

                Constants.CAP_MANAGER_ADDRESS = "XXXXXXXXXX";
                Constants.CAP_MANAGER_PORT = "8443";

                CapabilityManager.initialize(getApplicationContext());
                IdemixManager.getInstance().setServiceURL(Constants.getCAP_MANAGER_END_POINT());
                Object token = CapabilityManager.getInstance().getCapabilityToken(proofSpec, credentialName, credentialBinaryFile, commitment, "GET", "device1");
                System.out.println("the obtained token" + token);

SocIoTal-Issuer-Server

The Issuer server is a web application implemented with Java servlets and XML-RPC which allows generating Idemix credentials for clients. Communications are done by https. The Issuer requires of a Web container like Apache Tomcat. The Tomcat must be configured to trust the CA. The Issuer server is release as a java war application that has to be deployed in the /webapps folder of the Tomcat server for its installation.

The Issuer is deployed in the University of Murcia http://host:port/idemix. It implements an XML-RPC server accessible by HTTPs that can be invoked at https://host:8443/idemix/xmlrpc. The Issuer requires client authentication with a valid certificate signed by the CA. Idemix provides an XML schema to define the structure of the credential to be issued by the Issuer. During the issuance protocol, the client must specify the particular credential specification that wants to obtain from the Issuer. That is, the identity attributes that are going to be included in the credential issued by the Issuer. The SocIoTal Issuer provides a predefined set of credential specifications, which are available at http://host:port/idemix/files/.

The following snipped of code shows an Idemix credential structure example, with 13 identity attributes, corresponding to the 13 attributes supported by our Keyrock instance:

<CredentialStructure xmlns="http://www.zurich.ibm.com/security/idemix/credentialStructure" xsi:schemaLocation="http://www.zurich.ibm.com/security/idemix/credentialStructure ./xsd/CredentialStructure.xsd">
<References>
    <IssuerPublicKey>http://host:port/idemix/files/ipk.xml</IssuerPublicKey>
</References>
<Attributes>
     <Attribute issuanceMode="known" name="id" type="string"/>
    <Attribute issuanceMode="known" name="userName" type="string"/>
    <Attribute issuanceMode="known" name="domain_id" type="string"/>
    <Attribute issuanceMode="known" name="name" type="string"/>
    <Attribute issuanceMode="known" name="active" type="string"/>
    <Attribute issuanceMode="known" name="email" type="string"/>
    <Attribute issuanceMode="known" name="nickName" type="string"/>
    <Attribute issuanceMode="known" name="country" type="string"/>
    <Attribute issuanceMode="known" name="locality" type="string"/>
    <Attribute issuanceMode="known" name="postalCode" type="string"/>
    <Attribute issuanceMode="known" name="streetAddress" type="string"/>
    <Attribute issuanceMode="known" name="department" type="string"/>
    <Attribute issuanceMode="known" name="organization" type="string"/>
</Attributes>
<Features/>
<Implementation>
    <AttributeOrder>
         <Attribute name="id">1</Attribute>
        <Attribute name="userName">2</Attribute>
        <Attribute name="domain_id">3</Attribute>
        <Attribute name="name">4</Attribute>
        <Attribute name="active">5</Attribute>
        <Attribute name="email">6</Attribute>
        <Attribute name="nickName">7</Attribute>
        <Attribute name="country">8</Attribute>
        <Attribute name="locality">9</Attribute>
        <Attribute name="postalCode">10</Attribute>
        <Attribute name="streetAddress">11</Attribute>
        <Attribute name="department">12</Attribute>
        <Attribute name="organization">13</Attribute>
    </AttributeOrder>
</Implementation>
 </CredentialStructure>

The values of the user attribute required to be presented against the Issuer are included using the API and must follow the credential structure.

SocIoTal envisages improving the IdM to allow users to get an Idemix credential with identity information defined and stored in an external Identity Provider. In this sense, the Issuer can validate the identity attributes claimed by the client against a trusted Attribute Provider or IdP. Namely, we are considering integrate the SocIoTal IdM Issuer with the Fi-ware IdM. It will allow users registered in the Fi-ware IdM (KeyRock) to obtain credentials with their smartphones, derive partial identities and use them to obtain authorizations tokens used directly against target devices.

IdM Issuer API

The Issuer functionality is implemented by the IdemixHandler class, which is in charge of handling the incomings calls received by the IdemixIssuerServlet. It provides two main methods:

-BigInteger initiateIssueCredential(byte[] values, String credStruct_fn)

Given a credential structure and a set of attributes provided by the client, the Issuer validates that the client satisfices the attribute, if so it generates a nonce that is send back to the client. To validate the client attributes, the current version requires that the client includes the attributes values in its certificate that is signed by the CA.

  • byte[] computeRound2(byte[] message)

It receives as input an Idemix cryptographic message which has been computed previously by the client. Such a message is constructed based on the once obtained previously, the credential structure and the attributes values.

  • authenticate (username, userpass)

This method allows authenticate keyrock users by means of login-password. The keyrock authentication service is provided by the Issuer entity. Although the authentication end-point is different from the issuer-end-point the address/port are the same. Parameters are passed in the HTTP request.

The method returns the barer token Id generated by Keyrock that can be used afterwards as header for SSO. The response token is included in the http response in the header “X-Subject-Token”

  • authenticate (tokenId)

This method allows authenticate the user by presenting a valid keyrock token id. Notice that to obtain this token id, the user needs to be authenticate previously by user-password. This service, in turn, validates internally the presented token against the keyrock. As parameter the tokenId is passed to the service through the header “X-Subject-Token”. This method returns a barer token Id ( generated by Keyrock) that can be used afterwards as header for SSO. The response token is included in the http response in the header “X-Subject-Token”

  • getEntityAttributes (tokenId)

This method allows obtaining the user’s attributes stored in keyrock. It requires as parameter valid authentication token obtained using the method above. The parameter tokenId is passed to the service through the header “X-Subject-Token”. This method returns a barer token Id generated by Keyrock that can be used afterwards as header for SSO. The response token is included in the http response in the header “X-Subject-Token”

SocIoTal Verifier Server

The verifier server is a web application based on XML-RPC that allows validating partial identities, i.e. validate Idemix proofs related to an Idemix credential obtained from the Issuer server. Idemix requires agreeing a particular proof specification, between the client and the Verifier. In other words, both entities must agree on a specific structure of the partial identity, with the attributes from the full credential that are going to be shown and verified in the verification process.

The proof specification is described following the Idemix ProofSpec XML schema. The SocIoTal provides a predefined set of credential specifications, which are available at http://host:port/idemix/files/. An example of a proof specification for the credential structure defined in Listing 1 is shown in Listing 2. As can be seen the proof specification is linked to a credential structure and contains, among other information, the values of the client attributes which are going to be demonstrated to the Verifier. Proof Specification example for partial structure identity definition:

<ProofSpec xmlns="http://www.zurich.ibm.com/security/idemix"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.zurich.ibm.com/security/idemix ./xsd/ProofSpecification.xsd">

  <Declaration>
    <AttributeId name="id1" proofMode="unrevealed" type="string"/>
    <AttributeId name="id2" proofMode="revealed" type="string"/>
    <AttributeId name="id3" proofMode="revealed" type="string"/>
    <AttributeId name="id4" proofMode="revealed" type="string"/>
    <AttributeId name="id5" proofMode="revealed" type="string"/>
    <AttributeId name="id6" proofMode="revealed" type="string"/>
    <AttributeId name="id7" proofMode="revealed" type="string"/>
    <AttributeId name="id8" proofMode="revealed" type="int"/>
    <AttributeId name="id9" proofMode="revealed" type="string"/>
    <AttributeId name="id10" proofMode="revealed" type="int"/>
  </Declaration>

   <Specification>
      <Credentials>
         <Credential name="someRandomName" credStruct="http://host:port/idemix/file/usercredstruct.xml">
            <Attribute name="Id">id1</Attribute>
            <Attribute name="NickName">id2</Attribute>
            <Attribute name="FirstName">id3</Attribute>
            <Attribute name="LastName">id4</Attribute>
            <Attribute name="NationalIdNumber">id5</Attribute>
            <Attribute name="Email">id6</Attribute>
            <Attribute name="Address">id7</Attribute>
            <Attribute name="PostalCode">id8</Attribute>
            <Attribute name="Country">id9</Attribute>
            <Attribute name="PhoneNumber">id10</Attribute>
         </Credential>
      </Credentials>

      <EnumAttributes/>
      <Inequalities/>
       <Commitments>
         <Commitment name="commitment1">
            <Exponent index="0">id3</Exponent>
            <Exponent index="1">id10</Exponent>
         </Commitment>
      </Commitments>
      <Representations/>
      <Pseudonyms/>
      <VerifiableEncryptions/>
      <Messages/>
      </Specification>
</ProofSpec>

Attributes values of the commitment are included using the API.

IdM Verifier API

The Verifier functionality is implemented by the IdemixVerifierHandler class, which is in charge of handling the incomings calls received by the IdemixVerifierServlet. It provides two main methods:

  • BigInteger initiateVerifier()

This method allows initiate the Idemix verification protocol. It returns a nonce from the verifier given a particular set of system parameters.

  • boolean verifyProof(byte[] proof, byte[] proofSpecification, byte[] nonce)

This method allows verifying an Idemix proof of having a credential issued by the Issuer. It requires as input a proof cryptographic message with the CL proof and the proof specification. The proof cryptographic message can contain a set of identity attributes with their values. Notice that this method cannot been invoked unless the initiate verifier method has been already invoked. This is controlled by the Verifier by means of the HTTP Session. Moreover, the nonce is different for each verification.

SocIoTal IdM-Enabled Capability Manager

The IdM-Enabled-Capability-Manager is a web application that allows users to obtain capability tokens using their partial identities. In other words, it allows authenticating and demonstrating their attributes by means of Idemix proofs of having a valid credential issued by the Issuer.

The IdM-Enabled-Capability Manager server implements the Verifier server functionality explained before. In addition after validating the partial identity the IdM-Enabled-Capability Manager allows generation of capability tokens.

The IdM-Enabled-Capability Manager interacts with the Policy Decision Point in order for it to make an authorization decision about generating a token for a given requested resource and action. The application is accessed by HTTPs. It requires a valid certificate for the client, signed by the CA.

Capability Manager API

In order to generate the token, the IdemixCMServlet requires three parameters in the http request.

  • action
  • device
  • resource

Notice that the servlet requires that the client performs the verification protocol before calling the servlet. This is controlled by the application by means of the HTTP session. The subject attributes are taken from the presented partial identity (the Idmeix proof)

The Capability Manager API relies on the Authorization Manager class which provides a main method for obtaining the capability token:

  • public String getCapabilityToken(PublicKey clientPublicKey, List subject_attributes, String action, String targetResource, String targetDevice) throws AuthorizationException

SocIoTal IdM KeyRock Client

Introduction

This Java library provides a basic API for identity management by implementing a Admin client to interact with the FIWARE KeyRock server. To carry out such communication, the SCIM 2.0 and Identity API v3 interfaces provided by this IdM are used. The library offers the following functionality:

  • Add a new entity (user or smart object) to IdM (SCIM 2.0 interface)
  • Delete a registered entity in the IdM (SCIM 2.0 interface)
  • Update the attributes of a registered entity in the IdM (SCIM 2.0 interface)
  • See the attributes of a registered entity in the IdM (SCIM 2.0 interface)
  • Authenticate a registered entity in the IdM (SCIM 2.0 and Identity API v3 interfaces)
  • Validate a authentication of registered entity in the IdM (Identity API v3 interface)

Next, the implementation details and some aspects of interest on the deployed KeyRock instance are shown.

Client library data model

The library defines classes to model basic identity management concepts. These classes are described below:

Active

This class models “the user’s administrative status” of an entity. Its attributes are: o boolean value. The user’s administrative status

Address

This class models “a physical mailing address” of an entity user. Its attributes are:

  • String type. The address type (“home”, “work” or others)
  • String streetAddress. The full street address
  • String locality. The city or locality
  • String postalCode. The zip code or postal code
  • String country. The country name

Department

This class models “a department” of an entity user. Its attributes are:

  • String value. The name of a department

Domain

This class models “the domain” of an entity. Its attributes are:

  • String domain_id. The unique domain identifier

Email

This class models “an e-mail address” of an entity user. Its attributes are:

  • String value. The email address

Id

This class models “a unique identifier” for an entity. Its attributes are:

  • String value. The entity’s unique identifier

ManufacturerName

This class models “the manufacturer’s name” of an entity smart object. Its attributes are:

  • String value. The manufacturer’s name

Model

This class models “the model” of an entity smart object. Its attributes are:

  • String value. The model

Name

This class models “the name” of an entity user. Its attributes are:

  • String formatted. The full name (middle names, titles, etc.)

NickName

This class models “the casual way” to address an entity user in real life. Its attributes are:

  • String value. The nickname

Organization

This class models “an organization” of an entity user. Its attributes are:

  • String value. The name of an organization

Password This class models “the password” of an entity. Its attributes are:

  • String value. The password

UserName

This class models “the service provider’s unique identifier” of an entity user. Its attributes are:

  • String value. The service provider’s unique identifier

X509Certificate

This class models “a X.509 certificate” of an entity. Its attributes are:

  • String value. The X.509 certificate

Attribute

This class models “an attribute” of an entity. Its attributes are:

  • String name. The attribute name
  • T value. The parameterized attribute’s value
  • boolean readOnly. It indicates if the attribute can be modified

Entity

This class models “an entity” in an IoT context. All attributes of this class comply with SCIM standard (RFC 7643 SCIM Core Schema) and they are:

  • Attribute id. The unique identifier for an entity
  • Attribute domain. The entity’s domain
  • Set<Attribute<? extends Serializable>> attributes. The set of optional attributes of the entity. Some of these attributes are:
  • NickName nickName. The casual way to address an entity user in real life
  • Name name. The components of the user’s name
  • ArrayList
    addresses. The physical mailing addresses of an entity user
  • ArrayList emails. The e-mail addresses of an entity user
  • Organization organization. It identifies the name of an organization
  • Department department. It identifies the name of a department
  • ArrayList< X509Certificate> x509Certificates. The X.509 certificates associated with the entity
  • String password. The entity's clear text password
  • boolean active. A value indicating the entity's administrative status

User

This class models “a user” in an IoT context and it extends the Entity class. Its attributes are:

  • Attribute userName. The unique identifier for the user, typically used to directly authenticate to the service provider. This attribute is mandatory.

SmartObject

This class models “a smart object” in an IoT context and it extends the Entity class. SmartObject class is not modelled yet. Some of its attributes can be these (they do not appear in RFC 7643 SCIM Core Schema). Both attributes would be mandatory:

  • Attribute manufacturerName. The manufacturer’s name of the smart object
  • Attribute model. The smart object model

API description

The java client implements the described API functionality in the previous section by KeyRockIdentityManager class. The implemented methods are:

  • void addEntity (Entity entity) throws IdentityManagementException; This method allows registering a new entity (user or smart object) in the IdM KeyRock. If the entity was already registered, an IdentityManagementException type exception is thrown.

  • void removeEntity (Entity entity) throws IdentityManagementException; This method allows removing a registered entity (user or smart object) in the IdM KeyRock. If the entity was not registered, an IdentityManagementException type exception is thrown.

  • void removeEntity (String id) throws IdentityManagementException; This method allows removing a registered entity (user or smart object) in the IdM KeyRock using its unique id. If the entity was not registered, an IdentityManagementException type exception is thrown.

  • void updateEntity (Entity entity) throws IdentityManagementException; This method allows modifying registered entity’s attributes in the IdM KeyRock. If the entity was not registered, an IdentityManagementException type exception is thrown.

  • Entity getEntityById (String id) throws IdentityManagementException; This method allows consulting registered entity’s attributes in the IdM KeyRock using its unique id. If the entity was not registered, an IdentityManagementException type exception is thrown.

  • Entity getEntityByName (String name) throws IdentityManagementException; This method allows consulting registered entity’s attributes in the IdM KeyRock using its name. If the entity was not registered, an IdentityManagementException type exception is thrown.

  • Token authenticateById (String id, String password) throws IdMAdminException; This method allows authenticating a registered entity in the IdM KeyRock and generating an associated token to it using its unique id and its password. If the entity was not registered or the authentication process is wrong, the token is not generated.

  • Token authenticateByName (String name, String password) throws IdMAdminException; This method allows authenticating a registered entity in the IdM KeyRock and generating an associated token to it using its unique userName and its password. If the entity was not registered or the authentication process is wrong, the token is not generated.

  • Token getInfoToken (String token_id) throws IdMAdminException; This method allows validating the entity’s authentication using an associated token to it. If the token was not created through an above authentication process, the associated information to the token is not retrieved.

Finally, the TestKeyRockIdentityManagerClient class which shows the code for a basic usage example is provided.

KeyRock instance deployment

The library makes use of the SCIM interface provided by Keyrock. However, the current version of this IdM does not support many of the defined attributes in the SCIM standard (RFC 7643 SCIM Core Schema). Because of this, to register all attributes of the User class (described in the previous section) in the KeyRock, it was necessary to extend the User schema defined in the configuration of this IdM. Thus, it has deployed a KeyRock instance which, currently, supports the following attributes: id, userName, domain, nickName, name, addresses, emails, organization, department, x509Certificates, password, active. These attributes could be extended.

Three important aspects of this instance are:

  • It is deployed at the host and the port could be changed.
  • It is required the usage of the admin account to make use of the SCIM interface provided by this IdM. Thus, to obtain the password-token for the admin user, contact with Jorge Bernal (UMU) jorgebernal at um.es. This token will be included in the headers of the requests to KeyRock (X-Auth-Token header).
  • The SCIM interface is compatible with the current Identity API v3, i.e., entities created by the former can be consulted by the latter and vice versa.
You can’t perform that action at this time.