Conteúdo


Atribuição de Identidade com Liberty Profile em z/OS e CICS

Usando WebSphere Optimized Local Adapter (WOLA)

Comments

Pré Requisitos

Conhecimentos básicos de aplicações JEE, WebSphere e CICS. WebSphere Application Server (WAS) for z/OS Liberty Profile V8.5.5 ou superior (no artigo foi utilizada a versão 8.5.5.7), WebSphere Optimized Local Adapter (WOLA), Java Connector Architecture (JCA), Resource Access Control Facility (RACF) e IBM Rational Application Developer for z/OS (RDZ).

Não estão incluídos detalhes de instalação e configuração dos produtos já cobertos por outros artigos de diferentes fontes, mas há diversos links no final do artigo onde estas informações podem ser encontradas. Também estão anexados: arquivos de configuração, instalável da aplicação, código Java e COBOL.

Este tutorial é sobre o acesso a programas CICS a partir aplicações Java-EE executando em uma Liberty Profile do WAS, utilizando o adaptador local de alto desempenho WOLA.

O WOLA é um adaptador que permite a comunicação local e bidirecional entre um servidor WAS (Liberty ou Full Profile) e um processo no z/OS. Este processo pode ser um programa batch ou on-line, nesse caso rodando sob IMS ou CICS. Através do WOLA, uma aplicação Java no WAS pode acessar uma aplicação no z/OS, ou ser acessada por ela, desde que ambos executem na mesma partição (LPAR). Aqui vamos nos restringir às aplicações “outbound”, ou seja, originadas no WAS e acessando um programa no CICS.

Vale a pena mencionar que existem outros adaptadores para acesso remoto ao CICS e ao IMS, entre os quais o CICS Transaction Gateway (CTG). O WOLA é um adaptador com duas características que o diferenciam, é local (mesma LPAR) e bi-direcional.

O problema de Identidade no Acesso entre Sistemas

Ao acessar sistemas como o CICS a partir de aplicações Java Enterprise, geralmente se utiliza um usuário de serviço (usuário genérico), cuja identificação e senha são configurados na “connection factory” e passados pelo software ao fazer a conexão. A figura 1 mostra a situação:

Figura 1. Acesso ao CICS

Quando Elisa ou Carlos acessam a aplicação Java no WAS, são obrigados a se autenticar. Neste exemplo o WAS está configurado para realizar a autenticação em um servidor LDAP (Ligthweight Directory Access Protocol). Porem, o usuário sob o qual a aplicação CICS executa é sempre o usuário genérico (GENUSER na ilustração), não importa quem seja o usuário real. Proceder dessa maneira é simples e eficiente, a mesma conexão pode ser aproveitada em transações sucessivas por diferentes usuários, sem ter que autenticar novamente. Por outro lado, perdemos rastreabilidade. Atualizações em bancos de dados, mensagens registradas em logs e outas ações realizadas sob o CICS não trarão as identidades dos usuários reais. Também há problemas de segurança, como exemplificado a seguir.

Em um servidor Liberty Profile utilizando WOLA, essa configuração seria como no exemplo, extraído do arquivo server.xml:

<connectionFactory jndiName="eis/legacy" containerAuthDataRef="olaauth">
    <properties.ola RegisterName="OLASERVER”/>
</connectionFactory>
<authData id="olaauth" user="genuser" password="{xor}Lz4sLCgwLTtt" />
  • “genuser” é um usuário registrado no sistema de segurança do z/OS com acesso à lógica de negócio no CICS a ser executada, por exemplo, um programa COBOL.
  • A senha de do usuário de serviço “genuser” está codificada apenas para evitar sua exposição acidental. Não é uma proteção criptográfica e é fácil revertê-la.
  • "OLASERVER” representa o servidor CICS.

O arquivo de configuração tem que ser protegido, inclusive contra a leitura. Sua exposição abre as portas à diversas transações no ambiente CICS. Mesmo protegido, o pessoal da área de infraestrutura sempre terá acesso a essa informação.

O Que é Atribuição de Identidade

Para evitar os problemas mencionados, servidores de aplicação como o WebSphere Application Server suportam técnicas de atribuição de identidade. Trata-se de dizer ao sistema servidor qual a identidade será utilizada ao acessá-lo. Não há verificação de senha mas, em contrapartida, a comunicação entre o WAS e o CICS deve ser segura, ou seja, a prova de intrusões. Como o WOLA é local, isso fica facilitado.

Conceitualmente há três formas de atribuição de identidade:

Cenário 1
Um usuário de serviço fixo registrado no sistema de destino, como o “genuser” do exemplo. Neste caso a vantagem é somente não utilizar a senha para autenticação. Continuamos sem rastreabilidade. Essa opção é suportada em chamadas entre servidores JEE (Java X Java), mas não pelo WOLA/CICS.

Cenário 2
Passar a identidade o usuário real para o sistema servidor. Essa é a melhor opção, mas exige que o usuário real seja “conhecido” pelo sistema CICS, ou seja, o mecanismo de autenticação deve ser o mesmo. Esta opção é o tema deste artigo. A figura 2 mostra a situação:

Figura 2. Atribuição de identidade

Como na situação anterior, o WAS Liberty autentica Elisa e Carlos quando estes acessam aplicação pela primeira vez mas agora o servidor LDAP não é mais utilizado e sim o sistema de segurança do z/OS(RACF). Elisa e Carlos estão registrados no RACF e tem autorização para executar os programas no CICS. Todos os componentes da transação executam sob a autoridade do usuário real (Elisa/Carlos), inclusive as operações realizadas no banco de dados pelo programa. A rastreabilidade é total.

Cenário 3
A terceira opção é a “propagação de identidade”, uma combinação das duas outras. Nesse caso, o usuário é autenticado no sistema distribuído e sua identidade é mapeada para um usuário de serviço no sistema servidor. No processo de mapeamento, informações do usuário real são associadas ao usuário genérico, como mostrado na figura 3:

Figura 3. Propagação de identidade

Esta opção atualmente só é suportada na Liberty Profile que é parte do CICS TS 5.3 ou na Full Profile com o uso do CICS Transaction Gateway em lugar do WOLA. Não trataremos deste cenário aqui, apenas do cenário 2.

Aplicação Java

Para testar a atribuição de identidade, construí uma aplicação com um servlet e um EJB. O EJB faz uma chamada padrão JCA a um programa COBOL/CICS utilizando o WOLA. O Programa COBOL consulta informações de controle do z/OS através de chamadas ao CICS e devolve estas informações ao EJB. Ao final, o usuário autenticado no WAS e as informações extraídas pelo programa COBOL são mostrados no navegados para comparação. A seguir comento as partes importantes da aplicação.

O servlet é associado à URL LegacyUser, chamado na máquina usada para o teste como:
https://172.24.200.46:9443/COBCliWeb/LegacyUser

As partes relevantes do código são mostradas a seguir:

@WebServlet("/LegacyUser")
// @HttpConstraint(rolesAllowed="authservlet",
otransportGuarantee=TransportGuarantee.CONFIDENTIAL) //Does not work
public class LegacyUserServlet extends HttpServlet {
...
        @EJB(beanName="COBCliBean")
        COBCliBeanLocal lbean;

Tivemos que comentar a anotação de segurança do servlet (HttpConstraint). Diferentemente do ocorrido com o EJB (mais adiante) esta não funcionou, ou seja, o servidor permitiu o acesso por usuários não autenticados. Como é necessário proteger a aplicação de acessos não autorizados, usamos o deployment descriptor (web.xml) em lugar da anotação. Na configuração mostrada abaixo, só são permitidos métodos HTTP GET e POST e apenas os usuários da role “authsetvlet” podem acessar a aplicação:

<security-constraint>
	<web-resource-collection>
		<web-resource-name />
		<url-pattern>/*</url-pattern>
		<http-method-omission>GET</http-method-omission>
		<http-method-omission>POST</http-method-omission>
	</web-resource-collection>
</security-constraint>
<security-constraint>
	<web-resource-collection>
		<web-resource-name />
		<url-pattern>/*</url-pattern>
		<http-method>GET</http-method>
		<http-method>POST</http-method>
	</web-resource-collection>
	<auth-constraint>
		<role-name>authservlet</role-name>
	</auth-constraint>
	<user-data-constraint>
		<transport-guarantee>CONFIDENTIAL</...>
	</user-data-constraint>
</security-constraint>

É importante salientar a configuração de login, também no web.xml. Há dois tipos de configuração, basic e form authentication. Na basic authentication, o navegador é responsável por obter seu código de usuário e senha, através da conhecida janela de autenticação:

Figura 4. Autenticação básica

O problema é que o navegador coloca a informação de autenticação no cabeçalho da mensagem atual e todas as demais que enviar para o mesmo site. A qualquer momento, um código malicioso ou um vírus na aplicação pode interceptar a senha do usuário. Para evitar isso, recomenda-se o uso de form autentication, especificando uma página de login:

<login-config>
	<auth-method>FORM</auth-method>
	<form-login-config>
		<form-login-page>/logon.html</form-login-page>
		<form-error-page>/logonError.html</form-error-page>
	</form-login-config>
</login-config>

Obs.: A especificação JEE não define outra forma de configurar a página de login, apenas o web.xml. Não há anotação para isso.

A página logon.html é bem simples. Para um teste, não ha necessidade de embelezamento. O código HTML é o seguinte:

<!DOCTYPE HTML>
<html>
   <head>
      <title>logon</title>
      <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
   </head>
   <body>
      <form action="j_security_check" method=post>
         <p><strong>Please Enter Your User Name: </strong>
            <input type="text" name="j_username" size="25">
         <p>
         <p><strong>Please Enter Your Password: </strong>
            <input type="password" size="15" name="j_password">
         <p>
         <p>
            <input type="submit" value="Submit">
            <input type="reset" value="Reset">
      </form>
   </body>
</html>

Ao acessar a aplicação pela primeira vez, a página de login será exibida. A autenticação será feita pelo WebSphere. Isso é indicado pelo action padrão j_security-check. A tela é apresentada como mostrado na figura 5:

Figura 5. Login form

Uma vez autenticado o usuário, o servlet é executado. A resposta é enviada diretamente para o navegador, sem nenhuma formatação especial, conforme o código mostrado:

protected void doPost ... {
    try {
                response.getWriter().println(request.getRemoteUser() +
"/" + lbean.getUser());
            } catch (Exception e) {...
            } finally {
                response.setHeader("Cache-Control", "no-cache");
                response.setHeader("Pragma", "no-cache");
                response.setHeader("Expires", "0");
                response.getWriter().flush();

A resposta para o usuário é a concatenação de “request.getRemoteUser”, que identifica o usuário conforme autenticação feita pelo servidor de aplicação e o resultado da chamada ao método “getUser” do EJB, que mostramos a seguir:

public String getUser() throws ResourceException {
            Connection conn = cf.getConnection();
            CICSUserCommarea input = new CICSUserCommarea();
            ...
            CICSUserCommarea output = new CICSUserCommarea();
            Interaction inter = conn.createInteraction();
            try {
                    inter.execute(is, input, output);
                    return output.getCics__user();
            } finally {
                 inter.close();
                 conn.close();
            }
    }

A variável cf contém a "connection factory" enquanto is é um objeto do tipo "interaction spec". Ambos instanciados na inicialização do EJB.

Os parâmetros para o programa CICS são passados através de um objeto do tipo COMMAREA que traduz os parâmetros recebidos pelo programa CICS. Embora o programa use uma única área de parâmetros para entrada e saída, a chamada JCA especifica áreas separadas. O programa devolve a identidade do usuário de execução no CICS e esta informação é devolvida ao servlet.

A classe Java CICSUserCommarea corresponde à área de parâmetros do programa CICS e faz o trabalho de conversão entre Java e COBOL. Este objeto é criado a partir do código COBOL. Há duas formas de fazer isso: em batch com JZOS, um componente do Java do z/OS e com o uso do RDZ na estação do desenvolvedor. A área de parâmetros é a seguinte:

01 DFHCOMMAREA.
  03 CICS-USER     PIC X(8).
  03 RACF-RREALM   PIC X(256).
  03 RACF-RUSER    PIC X(256).

As informações RACF-RREALM e RACF-RUSER identificam o usuário remoto mapeado no cenário 3 (propagação de identidade). Embora não consideremos este cenário aqui, o programa COBOL já está preparado para ele.

Resta mostrar a construção do EJB e como as variáveis cf e is são inicializadas:

@Stateless
@TransactionManagement(value=TransactionManagementType.CONTAINER)
@TransactionAttribute(value=TransactionAttributeType.NOT_SUPPORTED)
@RolesAllowed("authejb")
@Local(COBCliBeanLocal.class)
@Remote(COBCliBeanRemote.class)
@LocalBean
public class COBCliBean implements COBCliBeanRemote, COBCliBeanLocal {
        @Resource(lookup="eis/legacy")
        private ConnectionFactory cf;
        @Resource
        private SessionContext ctx;
        private InteractionSpec is = null;

Como a transação é uma consulta, especifiquei execução não transacional. Também protegi a execução especificando @RolesAllowed("authejb"). A “connection factory” (cf) é injetada. Já a “interaction spec” (is) é um tipo de objeto cuja definição depende de implementação, ou seja, suas propriedades são definidas pelo fornecedor. Para o WOLA, esse objeto contém a propriedade "service name", que é o nome do programa a ser chamado no CICS. Para fornecer a informação teríamos que fazer algo como:

((com.ibm.WebSphere.ola.InteractionSpecImpl)
is).setServiceName("CICSUSER")

Isso torna o código cliente dependente, preso à implementação. O pacote “com.ibm...ola”, suas classes e nomes de propriedades (ServideName) são proprietários. Uma aplicação assim não poderá utilizar outros meios de acesso ao CICS, como por exemplo CTG, sem ter o código modificado.

A especificação JCA permite que o fornecedor externalize suas classes proprietárias de forma que possamos passar os parâmetros por configuração. Infelizmente, isso não foi feito pelos desenvolvedores do WOLA. Para remediar, criei um arquivo de propriedades com o nome da classe e a propriedade:

isclass = com.ibm.WebSphere.ola.InteractionSpecImpl
serviceName = CICSUSER

A varável is é então inicializada no construtor do EJB, com ajuda da classe BeanUtils:

    public COBCliBean() {
    InputStream input = null;
    try {
            input =
this.getClass().getClassLoader().getResourceAsStream("COBCli.properties"
);
            if(input != null) {
                Properties props = new Properties();
                props.load(input);
                is = (InteractionSpec)
Class.forName(props.getProperty("isclass")).newInstance();
                BeanUtils.populate(is, new HashMap(props));

Programa Cobol

O código cobol é o seguinte:

  ID DIVISION.
  PROGRAM-ID. CICSUSER.
  ENVIRONMENT DIVISION.
  DATA DIVISION.
  WORKING-STORAGE SECTION.
  LINKAGE SECTION.
  01 DFHCOMMAREA.
  03 CICS-USER                PIC X(8).
  03 RACF-RREALM              PIC X(256).
  03 RACF-RUSER               PIC X(256).
  PROCEDURE DIVISION.
  1. EXEC CICS ASSIGN USERID(CICS-USER) END-EXEC.
*    EXEC CICS INQUIRE ASSOCIATION(EIBTASKN) DNAME(RACF-RUSER)
*              REALM(RACF-RREALM) END-EXEC.
EXEC CICS RETURN END-EXEC.

A primeira instrução recupera a identificação do usuário enquanto a segunda obtém dados do usuário remoto mapeado no caso do cenário 3. O realm identifica como o usuário remoto foi autenticado, podendo conter um nome de domínio ou uma identificação de servidor LDAP. Para o nosso teste (cenário 2) comentei esta instrução.

Configuração da Liberty Profile

A seguir mostraremos os detalhes relevantes da configuração do servidor WAS (server.xml). Foram usadas as seguintes "features” na Liberty Profile:

Permite autenticar no z/OS WOLA

<featureManager>
	<feature>zosSecurity-1.0</feature>
	<feature>zosTransaction-1.0</feature>
	<feature>zosLocalAdapters-1.0</feature>
	<feature>ssl-1.0</feature>
	<feature>restConnector-1.0</feature>
	<feature>appSecurity-2.0</feature>
	<feature>jsp-2.3</feature>
	<feature>cdi-1.2</feature>
	<feature>jca-1.7</feature>
	<feature>jndi-1.0</feature>
	<feature>localConnector-1.0</feature>
	<feature>ejbLite-3.2</feature>
</featureManager>

A segurança básica foi configurada como se segue:

<keyStore id="defaultKeyStore" password="passw0rd" />
<safRegistry id="saf" />
<administrator-role>
    <group>was</group>
</administrator-role>

A "key store” é necessária para armazenar os certificados digitais, uma vez que exigimos proteção de acesso (“<transport-guarantee>CONFIDENTIAL</...>”) no web.xml da aplicação. A definição “SAF registry” indica que vamos autenticar os usuários no z/OS. SAF (System Authorization Facility) refere-se à interface. A implementação da IBM é o RACF, presente na máquina de teste. A tag “<administrator-role>” determina que os usuários administradores deste servidor estejam no grupo “WAS” do RACF.

O servidor será acessado pelas portas 9080 (HTTP) e 9443 (HTTPS):

<httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080"
httpsPort="9443" />

A definição do adaptador WOLA e da "connection factory" ficou assim:

<zosLocalAdapters wolaGroup="Liberty" wolaName2="WOLA"
wolaName3="SERVER1" useCicsTaskUserId="true" />
<connectionFactory id="wolaCF" jndiName="eis/legacy">
	<properties.ola RegisterName="CICSAOR2" />
</connectionFactory>

Diferentemente de outros adaptadores, o WOLA exige que o outro processo se registre antes que seja possível realizar chamadas de parte a parte. Como pode haver diferentes servidores WAS na LPAR, cada instância de WAS é identificada por um nome de 3 partes. No caso de Full Profile, esse nome é composto pelos nomes de célula, nó e servidor, não podendo ser modificado. Para uma Liberty Profile, os nomes são de livre escolha, desde que a combinação seja única na LPAR. Quando o CICS se registrar, ele também fornecerá um nome, referenciado na connection factory como “register name” (CICSAOR2). O que ocorre pode ser lido da seguinte forma: Uma instancia do CICS registra-se com o nome “CICSAOR2” junto a uma instancia do WAS, identificada como “Liberty/WOLA/SERVER1”. O comando de registro do CICS será visto mais adiante.

O parâmetro useCicsTaskUserId="true" faz com que o usuário autenticado no WAS seja passado ao CICS.

Criei uma “shared library” para acomodar o Apache Bean Utils e o arquivo de propiedades usado na aplicação:

    <library id="lib">
        <fileset
dir="/usr/lpp/zWebSphere/Liberty/V8R5/usr/servers/server1/lib"
includes="*.jar" />
        <folder
dir="/usr/lpp/zWebSphere/Liberty/V8R5/usr/servers/server1/lib" />
        </library>

Na definição da aplicação notem a associação dos papéis (roles) necessários para o acesso, tanto ao servlet como ao EJB, com o grupo WAS (no RACF).

<application location="COBCliApp.ear">
	<classloader commonLibraryRef="lib" classProviderRef="ola" />
	<application-bnd>
		<security-role name="authservlet">
			<group name="was" />
		</security-role>
		<security-role name="authejb">
			<group name="was" />
		</security-role>
	</application-bnd>
</application>

CICS

Para permitir a atribuição de identidade é necessário que o CICS seja iniciado com os parâmetros XUSER e XTRAN ligados. Estes parâmetros são informados no SYSIN do JCL de execução do CICS. A saída (SYSOUT) mostrará os parâmetros usados:

13.19.09 STC06455 IEF695I START CICSAOR2 WITH JOBNAME CICSAOR2 IS ASSIGNED TO
USER SYSSTC , GROUP SYSPROC
13.19.09 STC06455 $HASP373 CICSAOR2 STARTED
13.19.09 STC06455 IEF403I CICSAOR2 - STARTED - TIME=13.19.09
…
13.19.09 STC06455 DFHPA1927 CICSACB2 XTRAN=YES,
00370062
...
13.19.09 STC06455 DFHPA1927 CICSACB2 XAPPC=NO,
00450038
13.19.09 STC06455 DFHPA1927 CICSACB2 XUSER=YES,
00460061
…

Pata iniciar o WOLA é necessário antes ativar uma rotina de comunicação com ambientes externos, a Task Related User Exit (TRUE). A ativação dos recursos é feita através da transação de controle do WOLA (BBOC), executada a partir de um terminal CICS:

BBOC START_TRUE

Uma vez que a TRUE está ativada, devemos iniciar o WOLA propriamente dito, usando a mesma transação de controle em um terminal CICS:

BBOC START_SRVR RGN=CICSAOR2 DGN=Liberty NDN=WOLA SVN=SERVER1 SVC=*
MNC=1 MXC=10 TXN=Y SEC=Y REU=N TRC=2

A comunicação é estabelecida da seguinte forma: O CICS identifica o WAS por DGN + NDN + SVN (Liberty + WOLA + SERVER1) e se registra com o nome RGN (CICSAOR2). A partir daí, para fazer cxNão resisto: Renata Béééé Buuuummhamadas a este CICS, basta usar o nome de registro (RegisterName="CICSAOR2") em uma connection factory no WAS, como mostrado anteriormente.

Nota: Em um ambiente real, a execução das duas transações de ativação acima deverá ser automatizada como parte da inicialização do CICS.

O WOLA utiliza as transações “Link Server” BBO$ e “Link Invocation” BBO# para executar programas no CICS. Quando configuramos atribuição de identidade, a transação BBO$ é responsável pela troca da identidade do usuário. Esta transação roda sob as credenciais do usuário que executou o registro (BBOC START_SRVR):

Figura 6. Execução

O diagrama acima pode ser lido como: O WAS e o CICS são started tasks do z/OS. Uma aplicação, executada no WAS pelo usuário ID acessa o CICS. A identidade do usuário é passada na conexão para a transação BBO$, que executa sob o usuário que emitiu o comando START_SRVR (LNKSRVID). A transação BBO$ inicia uma nova transação BBO#, já com a identidade do usuário trocada. A transação BBO# por sua vez executa o programa desejado. Nenhuma senha é passada ou verificada no processo.

Para que a transação BBO$ possa chamar a transação BBO# trocando a identidade do usuário, o operador que iniciou o WOLA a partir do terminal CICS (LNKSRVID) deve ter uma autorização especial de “surrogate” no RACF. Os comandos necessários seriam:

RDEFINE SURROGAT *.DFHSTART UACC(NONE)
SETROPTS CLASSACT(SURROGAT) RACLIST(SURROGAT)
PERMIT *.DFHSTART CLASS(SURROGAT) ID(LNKSRVID)
SETROPTS RACLIST(SURROGAT) REFRESH

Adicionalmente, o usuário ID deve ser autorizado no CICS a executar a transação BBO#.

A figura 7 mostra o teste da aplicação. Observem que pela configuração padrão do z/OS, a identificação de usuário é convertida em maiúsculas:

Figura 7. Teste

Próximos Passos

O cenário 2 exige a autenticação dos usuários no z/OS o que limita seu uso aos usuários internos: funcionários e colaboradores da empresa. Em geral, clientes e fornecedores não tem acesso direto ao z/OS.

Para quem tiver o CICS 5.3, o cenário 3 pode ser obtido configurando-se o JVMSERVER (a versão da Liberty Profile que é parte do CICS) com as features cicsts:security-1.0 e cicsts:distributedIdentity-1.0, juntamente com autenticação LDAP. Também é possível implementar o cenário 3 com o WAS Full Profile em qualquer ambiente acessando o CICS no z/OS via CTG.

Conclusão

Este estudo está baseado em algumas práticas de segurança de aplicações relacionadas a autenticação:

A autenticação por senha deve ocorrer o mais distante possível das aplicações de negócio. Lembrem-se que componentes JEE como HTTP Filters fazem parte da camada de aplicação, não sendo adequados para tratar informações sensíveis. A autenticação deve ser realizada pelo menos um nível acima. A regra vale tanto para servidores JEE (Websphere) como para os ambientes legados (CICS/IMS). Há duas razões para isso:

  • Proteção: O contêiner da aplicação está melhor equipado para evitar o acesso mal intencionado a informações de autenticação. Por exemplo, uma aplicação que tentasse invadir áreas de memória do CICS ou IMS sofreria uma “protection exception” seguida de um ABEND.
  • Separação de responsabilidades: A função de autenticação é um serviço fornecido por qualquer contêiner. Refazê-lo dentro da aplicação é uma perda de tempo, equivalente a reinventar a roda. Adicionalmente, a autenticação padrão da plataforma está preparada para integrar a autenticação entre as várias aplicações e entre outros contêineres. Foi exatamente isso o que fizemos aqui, integrando a autenticação entre WAS e CICS. Implementar essa integração no código da aplicação seria insano.

Atualmente, novas técnicas como o SAML (Security Assertion Markup Language) foram criadas para aumentar a distancia entre a validação da senha e a aplicação. A autenticação passa a ser realizada em um servidor a parte, que produz um “ticket” com as informações do usuário. O ticket pode ser enviado de um servidor a outro, permitindo que vários componentes distribuídos da aplicação sejam executados sob a autoridade do usuário que iniciou a transação. Não importa se parte da aplicação é Java e outra parte .NET. Para evitar a possibilidade de fraudes, o ticket é assinado com o uso de técnicas criptográficas.

Outra técnica de autenticação, SPNEGO (Simple and Protected Negotiation) permite utilizar o ticket gerado para uma estação de trabalho Windows, quando o usuário se autentica na rede (domínio) da empresa. Como o usuário já está autenticado pelo servidor Windows (domain controler), ele pode acessar aplicações nos servidores da sua intranet sem uma nova autenticação.

Como vemos, a tendencia é reduzir a necessidade de validação de senha e o tráfego da mesma pela rede, ao mesmo tempo que distribuímos a identidade do usuário pelos vários componentes da aplicação. Com isso, mantemos a rastreabilidade e não recorremos a “usuários de serviço” e novas validações de senha.

Recursos

Código fonte e configurações: https://github.com/jtitop/IAWOLACICSZ

Informações sobre Liberty Profile no Developer Works, desde o básico. Inclui downloads do produto e ferramentas de desenvolvimento:
https://developer.ibm.com/wasdev/WebSphere-Liberty/

Como configurar Liberty Profile e WOLA no z/OS (conjunto de “techdocs” e vídeos com todas as informações):
https://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101490

Uma introdução ao WOLA, incluindo seu uso com WAS Full Profile:
WOLA Architectural Considensratios

Tutoriais sobre geração de código J2C:

Uso do cenário 3 com Liberty JVMSERVER no CICS TS 5.3:
https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.3.0/com.ibm.cics.ts.java.doc/topics/dist_identity.html?view=embed#distributed_identity


Recursos para download


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere
ArticleID=1039123
ArticleTitle=Atribuição de Identidade com Liberty Profile em z/OS e CICS
publish-date=10182016