spec.tex

%
%  OpenBus 2.0 Access Protocol
%
%  Created by Renato Maia on 2012-01-18.
%  Copyright (c) 2012 Tecgraf/PUC-Rio. All rights reserved.
%
\documentclass[]{article}

% Use utf-8 encoding for foreign characters
\usepackage[latin1]{inputenc}

% Setup for fullpage use
\usepackage{fullpage}

% Uncomment some of the following if you use the features
%
% Running Headers and footers
%\usepackage{fancyhdr}

% Multipart figures
%\usepackage{subfigure}

% More symbols
%\usepackage{amsmath}
%\usepackage{amssymb}
%\usepackage{latexsym}

% Surround parts of graphics with box
\usepackage{boxedminipage}

% Package for including code in the document
\usepackage{../mwlabinputs2}

% If you want to generate a toc for each chapter (use with book)
\usepackage{minitoc}

% This is now the recommended way for checking for PDFLaTeX:
\usepackage{ifpdf}

\newcommand{\term}[1]{\textit{#1}}
\newcommand{\code}[1]{\texttt{#1}}
\newcommand{\openbus}{\textsc{OpenBus}}
\newcommand{\version}{2.0}

%\newif\ifpdf
%\ifx\pdfoutput\undefined
%\pdffalse % we are not running PDFLaTeX
%\else
%\pdfoutput=1 % we are running PDFLaTeX
%\pdftrue
%\fi

\ifpdf
\usepackage[pdftex]{graphicx}
\else
\usepackage{graphicx}
\fi
\title{Protocolo de Acesso do \openbus{} \version{}}
\author{Tecgraf}

\date{\today}

\begin{document}

\ifpdf
\DeclareGraphicsExtensions{.pdf, .jpg, .tif}
\else
\DeclareGraphicsExtensions{.eps, .jpg}
\fi

\maketitle


\section{Introdução}

O protocolo de acesso do \openbus{} \version{} é o conjunto de regras para realização de chamadas CORBA através de um barramento \openbus{} que foi introduzido na versão \version{} do OpenBus.
O principal objetivo desse protocolo é garantir um nível adequado de segurança das chamadas que permita assegurar a identidade da entidade que iniciou cada chamada realizada através do barramento.

As chamadas através do barramento só podem ser realizadas através de um login de acesso autenticado em nome de uma entidade.
Cada entidade que acessa o barramento é identificada através de um nome único, denominado identificador de entidade.

A identificação da entidade que inicia cada chamada permite que as aplicações que respondem às chamadas possam aceitar ou rejeitar essas chamadas de acordo com os privilégios de cada entidade, assim como permitir a implementação de mecanismos de auditoria de utilização das aplicações e serviços integrados ao barramento.
As entidades que acessam o barramento podem ser diversas, tanto usuários humanos como sistemas computacionais.

O propósito deste documento é apresentar o protocolo de acesso do \openbus{} \version{} em detalhes, de forma que o protocolo possa ser implementado em diferentes linguagens.
Todo o protocolo de acesso do \openbus{} \version{} é baseado na arquitetura CORBA, fazendo uso particular o recurso de interceptadores de chamada (\term{CORBA Portable Interceptors}) para introduzir informações adicionais nas mensagens GIOP (\term{General Inter-ORB Protocol}) de CORBA.

\section{Chaves de Acesso} % (fold)
\label{sec:chaves_de_acesso}

Toda validação dos acessos ao barramento é feita através da troca de dados encriptados usando o algoritmo de chave pública RSA.
As chaves RSA utilizadas para esse acesso devem ter tamanho de 2048 bits~\footnote{O tamanho das chaves em bytes é dado pela constante IDL \code{::tecgraf::openbus::core::v2\_00::EncryptedBlockSize} que também indica o tamanho dos blocos encriptados com uma chave desse tamanho.}.
Chamaremos essas chaves RSA de \term{chaves de acesso}.

Para acessar o barramento, é necessário criar um par dessas chaves, sendo uma pública e outra privada.
A chave privada deve ser mantida secreta.
A posse da chave privada de acesso permite assumir a identidade de qualquer entidade autenticada no barramento usando a chave pública correspondente.

As chaves públicas de acesso são transmitidas entre os diferentes processos que acessam o barramento como uma sequência de bytes (\code{CORBA::OctetSeq}).
Para tanto as chaves públicas devem ser codificadas usando o formato \term{SubjectPublicKeyInfo} definido pelo padrão X.509, usando a codificação DER (\term{Distinguished Encoding Rules}).

Recomenda-se que cada processo que acesse um barramento \openbus{} utilize um único par exclusivo de chaves de acesso, evitando assim a geração excessiva de chaves. Contudo, é possível utilizar diferentes pares de chave de acesso, um para cada autenticação de uma entidade no barramento.

% section chaves_de_acesso (end)

\section{Processo de Login} % (fold)
\label{sec:processo_de_login}

O processo de login consiste basicamente em três atividades:
a autenticação de uma entidade através de algum método oferecido pelo \openbus{};
o registro da chave pública de acesso a ser utilizada na validação do acesso;
e a geração de identificador de login que é usado para identificar aquela autenticação da entidade junto ao barramento.

O login é feito através da faceta de nome \code{AccessControl} fornecida pelo \code{::scs::core::IComponent} do barramento, que implementa a seguinte interface:

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::AccessControl
interface AccessControl;
\end{samplecode}

Há basicamente três tipos de autenticação disponíveis para o processo de login, que serão descritos nas seções seguintes.

\subsection{Login por Senha} % (fold)
\label{sub:login_por_senha}

O login por senha é realizado através da operação \code{loginByPassword}, onde é fornecido o identificador da entidade a ser autenticada (\code{entity}), a chave pública de acesso (\code{pubkey}) e um bloco de dados encriptados (\code{encrypted}) com a chave pública do barramento, que é obtida através do atributo \code{buskey} desta mesma interface.

No caso do login por senha, os dados desse bloco encriptado é a seguinte estrutura codificada em CDR (encapsulado):

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::LoginAuthenticationInfo
struct LoginAuthenticationInfo {
	HashValue hash; // Hash da chave publica a ser associada ao login.
	OctetSeq data;  // Dado para autenticacao.
};
\end{samplecode}

\begin{description}
	\item[Campo \code{hash}] contém o hash SHA-256 do parâmetro \code{pubkey}.
	\item[Campo \code{data}] contém a senha de autenticação.
\end{description}

Como resultado de um login por senha bem sucedido a operação \code{loginByPassword} devolve a estrutura \code{LoginInfo} contendo o identificador do login e o identificador da entidade autenticada.
Adicionalmente, também é devolvido o tempo mínimo pelo qual o login permanecerá válido sem necessidade de renovação através do parâmetro de saída \code{lease}.

% subsection login_por_senha (end)

\subsection{Login por Certificado} % (fold)
\label{sub:login_por_certificado}

Uma segunda forma de autenticação junto ao barramento é através de certificados de autenticação registrados no barramento.
Nesse caso, para efetuar a autenticação é necessário ter a chave privada correspondente ao certificado registrado.

O login por certificado é feito em duas etapas.
Inicialmente, é necessário chamar a operação \code{startLoginByCertificate} onde é fornecido o identificador da entidade sendo autenticada (\code{entity}).
Como resultado, é devolvido um objeto para a conclusão do processo de login e um desafio (\code{challenge}), que consiste de um valor secreto gerado pelo barramento e encriptado com a chave pública do certificado registrado.

Para concluir o processo de login por certificado é necessário chamar a operação \code{LoginProcess::login} do objeto devolvido na etapa anterior, fornecendo uma chave pública de acesso (\code{pubkey}) e um bloco de dados encriptados (\code{encrypted}) com a chave pública do barramento, que é obtida através do atributo \code{buskey} desta mesma interface.

No caso do login por certificado, os dados desse bloco encriptado é estrutura \code{LoginAuthenticationInfo} codificada em CDR (encapsulado), onde os campos devem ser preenchidos da seguinte forma:

\begin{description}
	\item[Campo \code{hash}] contém o hash SHA-256 do parâmetro \code{pubkey}.
	\item[Campo \code{data}] contém o valor secreto, obtido pela desencriptação usando a chave privada correspondente ao certificado registrado no barramento do desafio (\code{challenge}) fornecido pela chamada da operação \code{startLoginByCertificate} da etapa anterior.
\end{description}

Similarmente à autenticação por senha, como resultado de um login por certificado bem sucedido, a operação \code{LoginProcess::login} devolve a estrutura \code{LoginInfo} contendo o identificador do login e o identificador da entidade autenticada.
Adicionalmente, também é devolvido o tempo mínimo pelo qual o login permanecerá válido sem necessidade de renovação através do parâmetro de saída \code{lease}.

% subsection login_por_certificado (end)

\subsection{Login por \term{Single Sign-On}} % (fold)
\label{sub:login_por_singlesignon}

Uma terceira forma de autenticação junto ao barramento é através do processo denominado \term{Single Sign-On}, em que uma entidade já logada permite que outra possa se logar usando a mesma autenticação original.
Nesse caso, para efetuar a autenticação é necessário primeiramente obter um desafio do barramento usando um login previamente estabelecido.

O login por \term{Single Sign-On} é feito em duas etapas.
Inicialmente, é necessário chamar a operação \code{startLoginBySharedAuth} usando um login estabelecido.
Como resultado, é devolvido um objeto para a conclusão do processo de login e um desafio (\code{challenge}), que consiste de um valor secreto gerado pelo barramento e encriptado com a chave pública de acesso do login estabelecido.

Para concluir o processo de login por \term{Single Sign-On} é necessário chamar a operação \code{LoginProcess::login} do objeto devolvido na etapa anterior, fornecendo uma chave pública de acesso (\code{pubkey}) e um bloco de dados encriptados (\code{encrypted}) com a chave pública do barramento, que é obtida através do atributo \code{buskey} desta mesma interface.

No caso do login por \term{Single Sign-On}, os dados desse bloco encriptado é estrutura \code{LoginAuthenticationInfo} codificada em CDR (encapsulado), onde os campos devem ser preenchidos da seguinte forma:

\begin{description}
	\item[Campo \code{hash}] contém o hash SHA-256 do parâmetro \code{pubkey}.
	\item[Campo \code{data}] contém o valor secreto, obtido pela desencriptação usando a chave privada de acesso do login que iniciou o processo de login por \term{Single Sign-On} do desafio (\code{challenge}) fornecido pela chamada da operação \code{startLoginBySharedAuth} da etapa anterior.
\end{description}

Similarmente à autenticação por certificado, como resultado de um login por \term{Single Sign-On} bem sucedido, a operação \code{LoginProcess::login} devolve a estrutura \code{LoginInfo} contendo o identificador do login e o identificador da entidade autenticada.
Adicionalmente, também é devolvido o tempo mínimo pelo qual o login permanecerá válido sem necessidade de renovação através do parâmetro de saída \code{lease}.

% subsection login_por_singlesignon (end)

% section processo_de_login (end)

\section{Credenciais de Chamada} % (fold)
\label{sec:credenciais_de_chamada}

Uma credencial no \openbus{} é um dado associado às chamadas feitas através do barramento que assegura a identidade da entidade que iniciou a chamada.
A credencial pode ser dividida em duas partes:
a identificação da entidade de quem iniciou aquela chamada;
e a identificação de todas as entidades que iniciaram cada chamada da cadeia de chamadas aninhadas onde esta chamada está inclusa.
À primeira parte da credencial daremos o nome de \term{personalidade} e à segunda parte de \term{cadeia de chamada}.

As credenciais do \openbus{} são transmitidas como um \term{service context} das mensagens GIOP de \term{Request} que indicam uma chamada remota, usando o  \term{context ID} definido pela constante abaixo:

\begin{samplecode}[language={[CORBA]idl}]
// File: credential.idl
// Name: ::tecgraf::openbus::core::v2_0::credential::CredentialContextId
const unsigned long CredentialContextId;
\end{samplecode}

\subsection{Personalidade} % (fold)
\label{sub:personalidade}

O conteúdo do \term{service context} da credencial consiste da codificação CDR (encapsulado) da estrutura abaixo:

\begin{samplecode}[language={[CORBA]idl}]
// File: credential.idl
// Name: tecgraf::openbus::core::v2_0::credential::CredentialData
struct CredentialData {
	Identifier bus;        // bus UUID
	Identifier login;      // caller UUID
	unsigned long session; // credential session identifier
	unsigned long ticket;  // monotonically increasing counter
	HashValue hash;        // SHA-256 hash
	services::access_control::SignedCallChain chain;
};
\end{samplecode}

\begin{description}

	\item[Campo \code{bus}] é o identificador do barramento onde o iniciador da chamada foi autenticado.
O identificador do barramento é obtido através do atributo \code{busid} da \term{Faceta de Controle de Acesso} do barramento.

	\item[Campo \code{login}] é o identificador de login do iniciador da chamada, que é obtido ao final do processo de login descrito na seção \ref{sec:processo_de_login}.

	\item[Campo \code{session}] é o identificador de uma sessão de geração de credencais.
	Basicamente, essa sessão indica o segredo emitido pelo recebedor da chamada que foi usado para geração da credencial.

	\item[Campo \code{ticket}] é um contador monotônico crescente.
	Cada credencial gerada com um mesmo segredo (ver campo \code{hash}) deve possuir um valor de \code{ticket} diferente, para impedir a reutilização de credenciais geradas.
	Idealmente, o valor do ticket deve ser incrementado de uma em uma unidade a cada geração de uma credencial, evitando que o lado que autentica as credenciais deva utilizar muita memória para lembrar de todos os tickets utilizados ou não utilizados.
	O lado da autenticação da credencial é livre para recusar credenciais com qualquer ticket, mesmo que estes nunca tenham sido utilizados em chamadas anteriores.

	\item[Campo \code{hash}] é o hash SHA-256 de um conjunto de dados que contém um segredo que só é conhecido pelas duas partes envolvidas nessa comunicação (quem inicia a chamada e a quem ela está endereçada).
	A seção \ref{sub:obtencao_do_segredo} descreve o processo de obtenção do segredo.
	Esse hash é recalculado pelo lado que autentica a credencial para verificar sua autenticidade.
	O conjunto de dados usado para o cálculo do hash consiste de uma sequência de bytes formada da seguinte maneira:

\begin{itemize}
	\item Um byte indicando a versão maior do protocolo~\footnote{Valor dado pela constante \code{tecgraf::openbus::core::v2\_00::MajorVersion}.};
	\item Um byte indicando a versão menor do protocolo~\footnote{Valor dado pela constante \code{tecgraf::openbus::core::v2\_00::MinorVersion}.};
	\item Uma sequência bytes que representa o segredo (tipicamente o segredo tem 16 bytes);
	\item 4 bytes com o valor do campo \code{ticket} da credencial (em \term{little endian});
	\item Uma sequência de bytes dos caracteres do nome da operação sendo chamada.
	Esse valor fornecido pelo interceptador de chamadas CORBA;
\end{itemize}

	\item[Campo \code{chain}] é a identificação da cadeia de chamadas aninhadas ao qual a chamada correspondente a essa credencial pertence.
	A seção \ref{sub:cadeia_de_chamadas} descreve cadeias de chamada.

\end{description}

\subsubsection{Validação da Personalidade} % (fold)
\label{sub:validacao_da_personalidade}

Ao receber uma chamada com uma credencial, é necessário validar a autenticidade dessa credencial.
Caso a credencial indique um identificador de barramento (campo \code{bus}) desconhecido, a chamada deve ser recusada com a exceção de sistema \code{CORBA::NO\_PERMISSION} com \code{COMPLETED\_NO} e o \term{minor code} dado pela seguinte constante:

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::UnknownBusCode
const unsigned long UnknownBusCode;
\end{samplecode}

Em seguida, é necessário verificar se o login informado é válido no barramento indicado.
Isso é feito através da operação \code{getLoginValidity} da faceta de nome \term{LoginRegistry}, que implementa a seguinte interface:

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::LoginRegistry
interface LoginRegistry;
\end{samplecode}

Caso o login informado não seja mais válido, a chamada deve ser recusada com a exceção de sistema \code{CORBA::NO\_PERMISSION} com \code{COMPLETED\_NO} e \term{minor code} dado pela seguinte constante:

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::InvalidLoginCode
const unsigned long InvalidLoginCode;
\end{samplecode}

Caso o login do iniciador da chamada for válido, é necessário recuperar o segredo compartilhado com aquele login correspondente à sessão indicada pelo campo \code{session} e utilizá-lo para recalcular o hash e comparar com o hash fornecido na credencial para averiguar a autenticidade da credencial.

Caso não haja nenhum segredo conhecido referente à sessão indicada pelo campo \code{session}, então a credencial deve ser considerada inválida, da mesma forma que uma credencial cujo campo \code{hash} não corresponde ao valor esperado, como será descrito posteriormente nesta seção.

Note que a ausência de um segredo conhecido referente à sessão indicada pelo campo \code{session} pode ser tanto porque é a primeira chamada proveniente do login informado na credencial ou porque o segredo compartilhado foi descartado por alguma política de gerência de memória.

Caso haja um segredo compartilhado com o iniciador da chamada, o hash da credencial deve ser recalculado como descrito anteriormente usando esse segredo conhecido e comparado com o hash fornecido na credencial.
Caso os valores de hash não sejam iguais, a credencial é considerada inválida e a chamada é recusada com a exceção de sistema \code{CORBA::NO\_PERMISSION} com \code{COMPLETED\_NO} e o \term{minor code} definido pela seguinte constante:

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::InvalidCredentialCode
const unsigned long InvalidCredentialCode;
\end{samplecode}

Adicionalmente, essa resposta da chamada deve vir juntamente com um \term{service context} com o \term{context ID} definido pela mesma constante \code{CredentialContextId} usada pelo \term{service context} contendo a credencial das chamadas enviadas.
Os dados do \term{service context} consitem da seguinte estrutura deve codificada em CDR (encapsulado):

\begin{samplecode}[language={[CORBA]idl}]
// File: credential.idl
// Name: tecgraf::openbus::core::v2_0::credential::CredentialReset
struct CredentialReset {
	Identifier target;        // callee entity
	unsigned long session;    // session ID
	EncryptedBlock challenge; // encrypted 16-byte random value (the secret)
};
\end{samplecode}

\begin{description}
	\item[Campo \code{login}] contém o identificador de login que recebeu a chamada.
	\item[Campo \code{session}] contém um novo identificador da sessão de geração de credenciais correspondente ao segredo fornecido no campo \code{challenge}.
	O identificador de sessão gerado deve ser diferente de qualquer sessão de geração de credenciais ativa entre o recebedor da chamada e o iniciador da chamada.
	\item[Campo \code{challenge}] contém um novo segredo encriptado com a chave pública de acesso associada ao login que iniciou a chamada.
	A obtenção da chave pública associada a qualquer login válido pode ser obtida através da operação \code{getLoginInfo} da \term{Faceta de Registro de Logins} do barramento.
	Caso a chave pública de acesso obtida não possa ser usada para codificar o segredo (ocorra um erro na encriptação devido à chave utilizada), então a chamada deve ser cancelada e uma exceção de sistema \code{CORBA::NO\_PERMISSION} com \code{COMPLETED\_NO} e o \term{minor code} definido pela seguinte constante:

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::InvalidPublicKeyCode
const unsigned long InvalidPublicKeyCode;
\end{samplecode}

	O segredo gerado deve ser uma sequência de 16 bytes gerado aleatoriamente e potencialmente diferente de qualquer outro segredo emitido previamente.
\end{description}

% subsubsection validacao_da_personalidade (end)

\subsubsection{Obtenção do Segredo} % (fold)
\label{sub:obtencao_do_segredo}

Para obter o segredo para geração de uma credencial para uma chamada, é necessário fazer uma chamada com uma credencial inválida.
Para tanto recomenda-se gerar uma credencial cujo valor dos campos \code{session} e \code{ticket} é zero, o campo \code{hash} é uma sequência de zeros e o campo \code{chain} é uma cadeia de chamada nula (veja seção \ref{sub:cadeias_para_o_barramento} sobre como gerar uma cadeia nula).
Neste caso, a credencial gerada será inválida, portanto o resultado deverá ser a exceção de sistema \code{CORBA::NO\_PERMISSION} juntamente com um \term{service context} informando o segredo a ser utilizado, conforme descrito acima.

% subsubsection obtencao_do_segredo (end)

% subsection personalidade (end)

\subsection{Cadeia de Chamadas} % (fold)
\label{sub:cadeia_de_chamadas}

A identificação da cadeia de chamadas é feita através de um dado assinado pelo barramento (com a chave privada do barramento).
Esse dado deve estar presente em todas as credenciais através do campo \code{chain}, que contém uma estrutura do seguinte tipo:

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: tecgraf::openbus::core::v2_0::services::access:control::SignedCallChain
struct SignedCallChain {
	EncryptedBlock signature; // Hash de 'encoded' assinado pelo barramento.
	OctetSeq encoded;         // estrutura 'CallChain' codificada usando CDR.
};
\end{samplecode}

\begin{description}
	\item[Campo \code{signature}] contém uma assinatura com a chave privada do barraemento do hash SHA-256 do campo \code{encoded}.
	
	\item[Campo \code{encoded}] contém a seguinte estrutura codificada em CDR (encapsulado):
	\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: tecgraf::openbus::core::v2_0::services::access:control::CallChain
struct CallChain {
	Identifier target;    // Node da entidade a quem a cadeia se destina.
  LoginInfoSeq originators; // Informações de login das entidades que realizaram as chamadas em cadeia que originam essa chamada.
  LoginInfo caller; // Informações de login da entidades que efetivamente fez chamada atual (última da cadeia).
};
	\end{samplecode}
	
	\item[Campo \code{target}] contém o nome da entidade a quem a cadeia está destinada.
	Ou seja, esse campo contém o mesmo identificador fornecido pelo campo \code{target} da estrutura \code{CredentialReset} descrito na seção \ref{sub:validacao_da_personalidade} que informa o login do objeto ao qual a chamada se destina.
	Esse campo \code{target} da cadeia garante que a cadeia só possa ser utilizada (fazer novas chamadas dentro daquela cadeia) por quem estiver logado como a mesma entidade ao quem ela foi enviada.
	
	\item[Campo \code{originators}] contém uma sequência de informações sobre os vários logins que realizaram as chamadas em cadeia que originam essa chamada.
	
	\item[Campo \code{caller}] login da entidades que efetivamente fez chamada atual (última da cadeia).
\end{description}

\subsubsection{Validação da Cadeia} % (fold)
\label{sub:validacao_da_cadeia}

É responsabilidade de quem recebe uma credencial de verificar a integridade da cadeia de chamada fornecida.
Para que a cadeia de chamada seja válida, as seguintes condições devem ser válidas:

\begin{itemize}
		\item O campo \code{SignedCallChain::signature} deve conter uma assinatura válida do campo \code{SignedCallChain::encoded} a ser autenticada com a chave pública do barramento.
	\item O campo \code{CallChain::target} deve ser o nome da entidade de quem recebe a chamada.
	\item O campo \code{CallChain::caller} deve indicar as informações do login de quem iniciou a chamada.
\end{itemize}

Se qualquer uma dessas condições não for válida, quem recebe a chamada deve recusar a chamada devolvendo a exceção de sistema \code{CORBA::NO\_PERMISSON} com \code{COMPLETED\_NO} e o \term{minor code} definido pela seguinte constante:

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::InvalidCredentialCode
const unsigned long InvalidChainCode;
\end{samplecode}

% subsubsection validacao_da_cadeia (end)

\subsubsection{Cadeias para o Barramento} % (fold)
\label{sub:cadeias_para_o_barramento}

Muitas chamadas para operações das facetas fornecidas pelo barramento são feitas usando credenciais de chamada como especificadas neste documento.
Contudo, as cadeias de chamada enviadas nas credenciais em chamadas ao barramento são diferente das cadeias enviadas em outras chamadas.

A identificação de que o objeto CORBA sendo chamado reside no barramento é feita comparando o campo \code{CredentialReset::target} com o identificador do barramento, que é obtido através do atributo \code{busid} da \term{Faceta de Controle de Acesso} do barramento.

Nas chamadas para o barramento, que são feitas fora de qualquer cadeia de chamada obtida previamente pelo iniciador da chamada, a cadeia a ser enviada na credencial é uma cadeia nula, que consiste da estrutura \code{SignedCallChain} em que o campo \code{signed} é uma sequência de zeros e o campo \code{encoded} é uma sequência vazia.

Nas chamadas para o barramento que são feitas dentro de uma cadeia de chamada obtida previamente pelo iniciador da chamada, a cadeia a ser enviada na credencial é a mesma cadeia originalmente obtida pelo iniciador, inalterada.
Ou seja, não é necessário gerar uma nova cadeia para enviar ao barramento, como é necessário nas credenciais para outros destinos como será visto na seção \ref{sub:geracao_de_cadeia}.

% subsubsection cadeias_para_o_barramento (end)

\subsubsection{Geração de Cadeia} % (fold)
\label{sub:geracao_de_cadeia}

Ao gerar uma credencial para uma chamada remota, é necessário gerar uma cadeia assinada pelo barramento para cada login de destino.
Isso é feito através da operação \code{signChainFor} da \term{Faceta de Controle de Acesso} do barramento.
A operação \code{signChainFor} deve ser chamada com uma credencial gerada usando as regras descritas neste documento.
Em particular, a credencial da chamada de \code{signChainFor} deve conter no campo \code{chain} a cadeia original a partir da qual a nova cadeia será gerada.
Ou seja, é como se a chamada de \code{signChainFor} é feita como uma chamada aninhada da cadeia de chamadas original.
Nesse sentido, para gerar uma cadeia nova que não seja uma extensão de outra cadeia previamente recebida, é necessário enviar uma cadeia nula na credencial da chamada de \code{signChainFor}, o que está em conformidade com a regra para geração de cadeias para o barramento, uma vez que a operação \code{signChainFor} é do barramento.

Como resultado da operação \code{signChainFor} é devolvida uma nova cadeia em que o campo \code{CallChain::caller} da cadeia original será adicionado à sequência do campo \code{CallChain::originators} e o campo \code{CallChain::caller} conterá informações do login de quem chamou a operação \code{signChainFor}.
Adicionalmente, o campo \code{CallChain::target} conterá o nome da entidade do identificador de login fornecido pelo parâmetro \code{target} da chamada de \code{signChainFor}.

Note que dessa forma é possível se adicionar a cadeias recebidas (processo denominado \term{join}), assim como gerar tais cadeias para quaisquer destinos para o qual seja necessário enviar credenciais.

% subsubsection geracao_de_cadeia (end)

% subsection cadeia_de_chamadas (end)

% section credenciais_de_chamada (end)

\appendix

\section{\term{Minor Codes} do \code{CORBA::NO\_PERMISSION}} % (fold)
\label{sec:minor_codes}

A seguir são descritos todos os valores de \term{minor code} usados nas exceções de \code{CORBA::NO\_PERMISSION} lançadas  nas comunicações usando o protocolo do \openbus{} \version{}.

\begin{tabular}{lp{10cm}}

\textbf{Nome}
&
\textbf{Descrição} \\

\hline

InvalidCredentialCode
&
A credencial informada na chamada é inválida.
Juntamente com essa exceção de \code{NO\_PERMISSION} deve sempre vir um \code{CredentialReset} com informações a serem usadas na geração de uma credencial válida. \\

InvalidChainCode
&
A cadeia de chamadas informada na chamada é inválida. \\

InvalidLoginCode
&
O login informado não é válido.
Isso ocorre quando o barramento informa a quem recebe a chamada que o login informado na chamada é inválido. \\

UnverifiedLoginCode
&
Não foi possível verificar o login informado por alguma razão.
Isso pode ocorrer quando quem recebe a chamada perde o login com o barramento ou não consegue acessar o barramento por alguma razão. \\

UnknownBusCode
&
Identificador do barramento na credencial é desconhecido.
Isso pode ocorrer quando quem recebe a chamada não está conectado no barramento informado. \\

\end{tabular}

% section minor_codes (end)

%\bibliographystyle{plain}
%\bibliography{}

\end{document}