spec.tex 28.8 KB
Newer Older
1
2
3
4
5
6
7
8
9
%
%  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
10
\usepackage[latin1]{inputenc}
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

% 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
32
\usepackage{../mwlabinputs2}
33
34
35
36
37
38
39
40
41

% 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}}
42
43
\newcommand{\openbus}{\textsc{OpenBus}}
\newcommand{\version}{2.0}
44
45
46
47
48
49
50
51
52
53
54
55
56
57

%\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
58
59
\title{Protocolo de Acesso do \openbus{} \version{}}
\author{Tecgraf}
60

61
\date{\today}
62
63
64
65
66
67
68
69
70
71
72
73

\begin{document}

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

\maketitle


74
\section{Introdução}
75

76
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.
77
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.
78
79

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

82
83
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.
84

85
86
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.
87
88
89
90

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

91
Toda validação dos acessos ao barramento é feita através da troca de dados encriptados usando o algoritmo de chave pública RSA.
92
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.}.
93
Chamaremos essas chaves RSA de \term{chaves de acesso}.
94

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

99
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}).
100
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}).
101

102
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.
103
104
105
106
107
108

% section chaves_de_acesso (end)

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

109
O processo de login consiste basicamente em três atividades:
110
a autenticação de uma entidade através de algum método oferecido pelo \openbus{};
111
112
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.
113

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

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

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

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

127
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.
128

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

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

\begin{description}
141
142
	\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.
143
144
\end{description}

145
146
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}.
147
148
149
150
151
152

% subsection login_por_senha (end)

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

153
154
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.
155

156
O login por certificado é feito em duas etapas.
157
158
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.
159

160
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.
161

162
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:
163
164

\begin{description}
165
166
	\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.
167
168
\end{description}

169
170
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}.
171
172
173

% subsection login_por_certificado (end)

174
175
176
177
178
179
180
\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.
181
Inicialmente, é necessário chamar a operação \code{startLoginBySharedAuth} usando um login estabelecido.
182
183
184
185
186
187
188
189
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}.
190
	\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.
191
192
\end{description}

193
194
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}.
195
196
197

% subsection login_por_singlesignon (end)

198
199
200
201
202
% section processo_de_login (end)

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

203
Uma credencial no \openbus{} é um dado associado às chamadas feitas através do barramento que assegura a identidade da entidade que iniciou a chamada.
204
205
206
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.
207
À primeira parte da credencial daremos o nome de \term{personalidade} e à segunda parte de \term{cadeia de chamada}.
208

209
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:
210
211
212

\begin{samplecode}[language={[CORBA]idl}]
// File: credential.idl
213
// Name: ::tecgraf::openbus::core::v2_0::credential::CredentialContextId
214
const unsigned long CredentialContextId;
215
216
217
218
219
\end{samplecode}

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

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

\begin{samplecode}[language={[CORBA]idl}]
// File: credential.idl
224
// Name: tecgraf::openbus::core::v2_0::credential::CredentialData
225
struct CredentialData {
226
227
228
229
230
	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
231
232
233
234
235
236
	services::access_control::SignedCallChain chain;
};
\end{samplecode}

\begin{description}

237
238
	\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.
239

240
	\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}.
241

242
243
244
	\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.

245
246
247
248
	\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.
249

250
251
252
253
	\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:
254
255

\begin{itemize}
256
257
258
259
	\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});
260
	\item Uma sequência de bytes dos caracteres do nome da operação sendo chamada.
261
	Esse valor fornecido pelo interceptador de chamadas CORBA;
262
263
\end{itemize}

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

\end{description}

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

272
273
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:
274
275
276

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

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

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

290
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:
291
292
293

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

298
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.
299

300
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.
301

302
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.
303

304
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.
305
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:
306
307
308

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
309
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::InvalidCredentialCode
310
const unsigned long InvalidCredentialCode;
311
312
313
\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.
314
Os dados do \term{service context} consitem da seguinte estrutura deve codificada em CDR (encapsulado):
315
316
317

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

\begin{description}
327
	\item[Campo \code{login}] contém o identificador de login que recebeu a chamada.
328
329
330
	\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.
331
	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.
332
333
334
335
	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
336
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::InvalidPublicKeyCode
337
338
339
const unsigned long InvalidPublicKeyCode;
\end{samplecode}

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

% subsubsection validacao_da_personalidade (end)

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

348
Para obter o segredo para geração de uma credencial para uma chamada, é necessário fazer uma chamada com uma credencial inválida.
349
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).
350
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.
351
352
353
354
355
356
357
358

% subsubsection obtencao_do_segredo (end)

% subsection personalidade (end)

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

359
360
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:
361
362
363

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

\begin{description}
372
	\item[Campo \code{signature}] contém uma assinatura com a chave privada do barraemento do hash SHA-256 do campo \code{encoded}.
373
	
374
	\item[Campo \code{encoded}] contém a seguinte estrutura codificada em CDR (encapsulado):
375
376
	\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
377
// Name: tecgraf::openbus::core::v2_0::services::access:control::CallChain
378
struct CallChain {
379
	Identifier target;    // Node da entidade a quem a cadeia se destina.
380
381
  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).
382
383
384
};
	\end{samplecode}
	
385
386
387
	\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.
388
	
389
390
391
	\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).
392
393
\end{description}

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

397
398
É 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:
399
400

\begin{itemize}
401
		\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.
402
	\item O campo \code{CallChain::target} deve ser o nome da entidade de quem recebe a chamada.
403
	\item O campo \code{CallChain::caller} deve indicar as informações do login de quem iniciou a chamada.
404
405
\end{itemize}

406
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:
407
408
409

\begin{samplecode}[language={[CORBA]idl}]
// File: access_control.idl
410
// Name: ::tecgraf::openbus::core::v2_0::services::access_control::InvalidCredentialCode
411
const unsigned long InvalidChainCode;
412
413
414
415
416
417
418
\end{samplecode}

% subsubsection validacao_da_cadeia (end)

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

419
420
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.
421

422
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.
423

424
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.
425

426
427
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}.
428
429
430

% subsubsection cadeias_para_o_barramento (end)

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

434
435
436
437
438
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.
439
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.
440

441
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}.
442
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}.
443

444
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.
445
446
447
448
449
450
451

% subsubsection geracao_de_cadeia (end)

% subsection cadeia_de_chamadas (end)

% section credenciais_de_chamada (end)

452
453
454
455
456
\appendix

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

457
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{}.
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494

\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)

495
496
497
498
%\bibliographystyle{plain}
%\bibliography{}

\end{document}