Autenticação do Portal com o Desktop do Windows

Este tema já foi explorado neste blog para a versão 6.0 do Portal. No post de hoje eu gostaria de explorar esta funcionalidade no Portal 6.1.

Na versão 6.1 do Portal o SPNego (componente presente no TAM), funciona como um TAI (trust association interceptor). Desta forma você consegue configurar o portal sem a necessidade de utilizar um software externo de autenticação para estabelecer uma comunicação kerberos com o IIS (Internet Information Server). O módulo kerberos que está no IIS consegue obter um token de confiança entre o Microsoft AD e o Windows.

Para fazer isso a configuração é bem simples. Abaixo segue um passo-a-passo.

1) Enabling and configuring the SPNEGO TAI

Enabling :
Perform the following steps to enable the Simple and Protected GSS-API Negotiation Mechanism trustassociation interceptor:
1. Log on to the WebSphere Application Server administrative console.
2. Click Security > Secure administration, applications, and infrastructure.
3. Click Web security and then click Trust association.
4. Ensure that the Enable trust association checkbox is checked and then click Interceptors.
5. Click New and then type com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl in theInterceptor class name text field.
6. Click OK and then click the Save link to save changes to the master configuration.

Configuring:
1.Log on to the WebSphere Application Server administrative console.
2.Click Security > Secure administration, applications, and infrastructure.
3.Click Web security and then click Trust association.
4.Ensure that the Enable trust association checkbox is checked and then click Interceptors.
5.Click com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl
6.Click Custom properties
7.Click New
8.Name : com.ibm.ws.security.spnego.SPN1.hostName
9.Value : portal61.ibdemo.com
10.Click Save
11.Click new to create a new property :
12.Name : com.ibm.ws.security.spnego.SPN1.filterClass
13.Value : com.ibm.ws.security.spnego.HTTPHeaderFilter
14.Click Save
15.You might have properties in the Custom Properties list as below :
Name = Value
com.ibm.ws.security.spnego.SPN1.hostName = portal61.ibdemo.com
com.ibm.ws.security.spnego.SPN1.filterClass = com.ibm.ws.security.spnego.HTTPHeaderFilter

Dica: Performance em buscar conteúdos no WCM

Muitas vezes os usuários pedem alguns layouts de conteúdos WCM bem complexos, e uma coisa é fato: O WCM tem algumas limitações na forma de exibir seus conteúdos. Uma das alternativas é usar a API do WCM para trazer seus conteúdos e apresentar da forma que quiser, já que assim estará trabalhando num JSP. Eis que vem um probleminha chato: Performance.

Apesar desse problema ter sido bem reduzido a partir da versão 6.1, para quem ainda está na 6.0 vai uma dica: Usar o Menu Component, se possível, para buscar os conteúdos que você precisa.
Quando usamos o Menu Component do WCM ao invés do searchContent(), nota-se um ganho imenso de performance, já que o Menu Component é gerenciado internamente para cachear os resultados e fazer o melhor método de acesso.

Para quem usa Portal 6.0:
A dica é escrever um XML como saída do Menu Component e os valores que você vai precisar exibir, já que não é possível pegar o conteúdo da iteração corrente no menu.
Ex:
Cabeçalho: [resultado]
Cada resultado: [conteudo][nome][placeholder...][url][placeholder...][/url]
Rodapé: [/resultado]

No WPF você converte o resultado do componente usando uma classe LJO e XmlUtil.parseXml(workspace.render(rc, menuComponent));

Para quem usa Portal 6.1:
Se precisar mesmo usar o WPF, faça como no exemplo acima, porém se puder resolver seu problema com um JSP incluído no resultado do menu, use o método renderingContext.getCurrentResultId();

;)

Limitações no uso de Ajax em portlets

Não tem nada mais eficiente hoje em dia do que atender as requisições dos usuários em uma chamada Ajax, principalmente em Portais, onde as vezes o conteúdo requisitado é apenas de um pequeno portlet dentre uma página cheia deles. Para isso, o WebSphere Portlet Factory provê alguns builders para trabalhar com Ajax, e a famosa seção "Post-action behavior" nos builders que o suportam.
Andei implementando essa funcionalidade esses dias, e notei algumas limitações importantes.

1. Toda requisição Ajax é delegada a um Servlet dentro da sua aplicação de portlet, e assim, você não possui o contexto de Portal. Ou seja, nem pense em recuperar o PortletRequest ou PortletResponse.

2. O contexto de segurança também não é passado, fiz alguns testes tentando recuperar o UserPrincipal da requisição, e o mesmo sempre retorna nulo. Conversei com o suporte da IBM e me informaram que isso não seria mesmo possível, NA VERSÃO 6.0, pois na versão 6.1 (Spec 286) o contexto do portlet é mantido através do Resource Serving.

Do resto, achei expetacular a facilidade de se implementar chamadas Ajax com o WebSphere Portlet Factory. Sem uma linha de código, consegui trazer algumas aplicações de portlet para o mundo Web 2.

Mais informações:
http://www.ibm.com/developerworks/websphere/library/techarticles/0711_cooke/0711_cooke.html
http://www-10.lotus.com/ldd/pfwiki.nsf/dx/learning-websphere-portlet-factory