Autenticación de IAM

Puede realizar las siguientes tareas con IAM:

• Gestionar el acceso de manera centralizada en IBM Cloud.
• Permitir a un usuario o servicio acceder a distintos recursos utilizando el mismo conjunto de credenciales (por ejemplo, el mismo usuario y contraseña o clave de API IAM).
• Es posible otorgar acceso a las claves de API IAM a las funciones de gestión de cuenta, como la creación de bases de datos nuevas.

Para obtener más información, consulte Gestión de acceso o una visión general de IAM.

Autenticación

Autenticarse significa demostrar quién es. Para demostrar su identidad, proporcione sus credenciales de usuario para su verificación.

La autenticación básica es comparable a mostrar un ID en una entrada para que se compruebe cada vez que desee pasar. La autenticación de cookies es comparable a tener una llave de la puerta para poder entrar en siempre que desee. Dentro de IBM Cloudant, la llave (o clave) es una cookie denominada AuthSession.

Cuando crea o utiliza aplicaciones críticas de IBM Cloudant, la autenticación de cookies tiene más ventajas en comparación con la autenticación básica. Le animamos a utilizar la autenticación de cookies siempre que sea posible.

Autorización

Después de autenticarse, la siguiente prueba consiste en decidir si tiene permiso para realizar determinadas tareas. Esta decisión se denomina autorización.

Cuando se autentica con el sistema IBM Cloudant, este "sabe" quién es usted. La siguiente pregunta es: ¿qué tareas se le permite realizar?

Puede crear una lista completa de todas las tareas posibles que puede realizar, para cada aspecto de un sistema IBM Cloudant, como por ejemplo una base de datos o un documento. Aunque resulta simple, este enfoque requeriría muchas listas largas. Mantener esas listas actualizadas y completa resulta impracticable.

Un enfoque mejor consiste en utilizar "roles". Las diversas tareas se pueden agrupar en colecciones que son típicas de algunos roles genéricos. Por ejemplo, la tarea de crear o suprimir una base de datos es característica de alguien con un rol administrativo. Del mismo modo, la tarea de crear o actualizar un documento es característica de alguien con un rol de "escritor".

En lugar de listar explícitamente cada tarea que puede hacer, se le otorgan uno o varios roles. Si tiene un rol, puede realizar todas las tareas asociadas a dicho rol.

Roles

La siguiente sección sólo se aplica a las credenciales heredadas. Para obtener más información sobre cómo utilizar roles con credenciales de IAM, consulte Roles deIBM Cloudant.

IBM Cloudant tiene diversos roles disponibles. Los roles se pueden asignar a cuentas de usuario o a claves de API.

En la tabla siguiente se definen los tres roles principales:

Los roles _reader y _writer son exclusivos. Si un usuario tiene el rol _writer, no puede leer los documentos que se crean a menos que también tenga el rol _reader.

Es posible que desee asignar más de un rol. Por ejemplo, es posible que un usuario tenga que leer o escribir en documentos dentro de una base de datos, pero no necesite un control administrativo completo sobre la base de datos. Para cumplir este requisito, a la cuenta del usuario se le otorgan los roles _reader y _writer, pero no el rol _admin.

También hay varios roles "focalizados" disponibles. Estos roles proporcionan permisos para puntos finales de API específicos. Los permisos de los roles focalizados son similares a los permisos de los roles principales, pero se aplican solo al punto final de API específico.

En la tabla siguiente se definen los roles focalizados:

La naturaleza del acceso que se otorga depende del punto final de API específico. Por ejemplo, el rol _design proporciona acceso que permite a un usuario o clave de API crear, leer, modificar o suprimir documentos de diseño. Si otorga acceso de este modo, la ventaja es que no es necesario que asigne los roles _reader o _writer que tienen una aplicación más amplia. Esta distinción es útil porque, de lo contrario, la cuenta autorizada podría leer o escribir en documentos dentro de la base de datos, que no sean los documentos de diseño.

Las credenciales que utiliza para iniciar sesión en el panel de control automáticamente tienen el rol _admin sobre todas las bases de datos que cree. A todos y a todo lo demás, incluidos los usuarios con los que comparte bases de datos y las claves de API que cree, se les debe asignar un rol de forma explícita para que puedan realizar las tareas correspondientes.

El nombre de usuario nobody especial se aplica a cualquiera o a cualquier aplicación que intente realizar tareas, pero no se ha autenticado con el sistema. Es decir, el nombre de usuario nobody se aplica a todos los intentos de conexión no autenticados. Por ejemplo, si una aplicación intenta leer datos de una base de datos, pero no se ha identificado, la tarea solo puede continuar si el usuario nobody tiene el rol _reader.

Se pueden otorgar roles más potentes a un usuario no autenticado que a un usuario autenticado. Por ejemplo, si el nombre de usuario de nobody se otorga intencionadamente _admin, A los roles _reader y _writer, pero a una cuenta de usuario autenticada como, por ejemplo, alexone, solo se le otorga el rol _reader. En este caso, es posible que el usuario no autenticado tenga un rol más potente que el usuario autenticado alexone.

Es importante comprender que el nombre de usuario de nobody no constituye una forma de proporcionar un conjunto predeterminado de permisos. El nombre de usuario nobody se utiliza para determinar los permisos para los usuarios no autenticados.

Claves de API

La siguiente sección sólo se aplica a las credenciales heredadas. Para obtener más información sobre el uso de claves API con credenciales IAM, consulte Claves API IAM.

Utilice claves de API para habilitar el acceso a bases de datos para una persona o aplicación, pero sin crear una nueva cuenta de IBM Cloudant para dicha persona o aplicación. Una clave de API es un nombre de usuario y contraseña generados aleatoriamente. A la clave se le otorgan los permisos de acceso deseados sobre una base de datos.

Cuando se genera una clave y se otorgan los permisos de acceso necesarios, la clave de API se puede utilizar de la misma forma que una cuenta de usuario normal.

Sin embargo, las claves de API no son iguales que las cuentas de usuario normales. Una clave de API no tiene acceso al panel de control.

Una clave de API se utiliza principalmente para permitir que las aplicaciones accedan a una base de datos, con un nivel determinado de control de acceso.

Todas las instancias de IBM Cloudant que se despliegan desde la región de IBM Cloud® pública de Alemania se despliegan en entornos gestionados por la UE. Cualquiera La cuenta de IBM Cloudant o la clave de API que se genera fuera de un entorno gestionado por la UE no puede obtener acceso a una instancia de IBM Cloudant gestionada por la UE. Para obtener más información sobre IBM Cloudant en un entorno gestionado por la UE, consulte Ubicaciones y arrendamiento.

Utilización de la base de datos _users con IBM Cloudant

La siguiente sección sólo se aplica a las credenciales heredadas.

Puede utilizar la Base de datos de _users para gestionar roles en IBM Cloudant.

Los documentos de usuario que se almacenan en la base de datos _users deben estructurarse y rellenarse para cumplir con los requisitos de Apache CouchDB Los requisitosApache CouchDB.

Puede inhabilitar las comprobaciones de autorización de IBM Cloudant con el parámetro couchdb_auth_only:true. Para inhabilitar la seguridad de IBM Cloudant, PUT a JSON document to the _security endpoint of the database. Por ejemplo, https://$ACCOUNT.cloudant.com/$DATABASE/_security.

Consulte el ejemplo siguiente en el que se utiliza HTTP para enviar una solicitud de modificación:

PUT /$DATABASE/_security HTTP/1.1
Content-Type: application/json

Consulte el ejemplo siguiente para enviar una solicitud de modificación:

curl -H "Authorization: Bearer $API_BEARER_TOKEN" -X PUT "$SERVICE_URL/products/_security" -H "Content-Type: application/json" --data '{"members": {"names": ["user1", "user2"], "roles": ["developers"]}}'

import com.ibm.cloud.cloudant.v1.Cloudant;
import com.ibm.cloud.cloudant.v1.model.Ok;
import com.ibm.cloud.cloudant.v1.model.PutSecurityOptions;
import com.ibm.cloud.cloudant.v1.model.SecurityObject;

import java.util.Arrays;

Cloudant service = Cloudant.newInstance();

SecurityObject members = new SecurityObject.Builder()
    .names(Arrays.asList("user1", "user2"))
    .roles(Arrays.asList("developers"))
    .build();

PutSecurityOptions securityOptions =
    new PutSecurityOptions.Builder()
        .db("products")
        .members(members)
        .build();

Ok response =
    service.putSecurity(securityOptions).execute()
        .getResult();

System.out.println(response);

const { CloudantV1 } = require('@ibm-cloud/cloudant');

const service = CloudantV1.newInstance({});

const members: CloudantV1.SecurityObject = {
  names: ['user1', 'user2'],
  roles: ['developers']
};

service.putSecurity({
  db: 'products',
  members: members
}).then(response => {
  console.log(response.result);
});

from ibmcloudant.cloudant_v1 import CloudantV1, SecurityObject

service = CloudantV1.new_instance()

members = SecurityObject(
  names=['user1', 'user2'],
  roles=['developers']
)

response = service.put_security(
  db='products',
  members=members
).get_result()

print(response)

putSecurityOptions := service.NewPutSecurityOptions(
  "products",
)
putSecurityOptions.SetMembers(&cloudantv1.SecurityObject{
  Names: []string{"user1", "user2"},
  Roles: []string{"developers"},
})

ok, response, err := service.PutSecurity(putSecurityOptions)
if err != nil {
  panic(err)
}

b, _ := json.MarshalIndent(ok, "", "  ")
fmt.Println(string(b))

El ejemplo Go anterior requiere el siguiente bloque de importación:

import (
   "encoding/json"
   "fmt"
   "github.com/IBM/cloudant-go-sdk/cloudantv1"
)

Todos los ejemplos de Go requieren que se inicialice el objeto service. Para obtener más información, consulte los ejemplos de la Sección de autenticación de la documentación de la API.

Consulte la siguiente solicitud de modificación de ejemplo en formato JSON:

{
	"couchdb_auth_only": true,
	"members": {
		"names": ["member"],"roles":[]
	},
	"admins": {
		"names": ["admin"],"roles":[]
	}
}

Consulte la siguiente respuesta de ejemplo de una solicitud de modificación:

{
	"ok" : true
}