Etiqueta: identity

Ortografía del código

En la actualidad (y desde hace buen tiempo), varios entornos de desarrollo y editores de código tienen la capacidad de detectar «errores» ortográficos de forma similar a lo que hacen los procesadores de texto como Microsoft Word y Google Docs que subrayan las palabras que desconocen.

En general esta funcionalidad de «corrección ortográfica» viene configurada para inglés. Si codeamos en inglés (cosa que muchos programadores hacen) no hay problema. Pero si aplicamos Domain-Driven Design y nuestro usuario/cliente habla castellano, entonces seguramente codeemos en castellano y ahí el IDE/editor comenzará a que llamarnos la atención. Aquí tenemos básicamente dos opciones: desactivar la verificación de ortografía o configurarla correctamente. Para esto último, independientemente de cómo sea esa configuración seguramente vamos a necesitar descargar un diccionario.

En el video que comparto a continuación explico como configurar RubyMine, el IDE de JetBrains para Ruby, pero la configuración es práctica igual para otros IDEs de JetBrains.

Bonus: para el caso de Visual Studio Code, podemos instalar la extensión Spanish – Code Spell Checker, en otro momento lo explicaré con más detalle.

Claim-based identity (part#1)

During this week I ‘ve been working with federated identity a very interesting topic that every day sounds more and more. This post is the first part of a quickstart I plan to write to help beginners to understand the stack of protocols involved in the solution to this common problem and in particular to Microsoft’s solution for it: codename «Geneva».

Let’s start by getting familiar with some vocabulary:

  • Security token: it is a serialized set of claims that in most of the cases is digitally signed by an issuing authority.
  • Issuing authority: any entity you trust.
  • Security Token Service (STS): is a software component (exposed by an issuing authority) applications trust for authetication.
  • Relaying party (RP): is an aplication that trust in the STS.
  • Claim: information about the user contained in a security token and required by a application (RP app.). In some point claims are analogous to attributes in the enterprise directory world.
  • identity provider STS (IP STS): is an STS capable of authenticate users, determining user identity tipically by validating his credentials (username & password).
  • Relaying party STS (RP STS): is an STS that relies in others STS to authenticate users and has the ability to generate the claims required by the relaying party application.

What is Geneva?

It is a set of Microsoft tecnologies that implements the shared industry vision for an interoperable identity metasystem. It comprises 3 components:
  • Geneva server (ADFS)
  • Windows Cardspace Geneva (CardSpace)
  • Geneva framework (Windows Identity Foundation)
If you are thinking in implementing an identity solution you must take a look at Geneva. Good starting points are the Identity Training Kit and this white paper. Depending on what you plan to do it is possible you need to understand how the things work under Geneva’s hood, I will try to give you some ligth about it starting by some web services protocols.

WS-* protocols

WS-* is a set of interoperable protocols to solve common concenrs (like security and confidentiality) when building enterprise applications. When  working with Geneva some of this protocols are involved:
  • WS-Security: is a protocol that define some extension to SOAP that can be used when building secure Web services to implement message content integrity and confidentiality. (see ws-security specification)
  • WS-Trust: is an extension to WS-Security that defines methods for issuing, renewing, and validating security tokens and ways to establish assess the presence of, and broker trust relationships. It is used by STSs to expose endpoints. This video by Vittorio Bertocci explains this protocol in a very clear way, or you can also read the ws-trust specification.
  • WS-Policy: provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. In out context it is used is used by RP app/service to expose the required policy to be invoked. (see ws-policy specification)
  • SAML: is an XML-based standard for exchanging authentication and authorization data in the kind of tokens. Our tokens are expressed with SAML.
  • WS-Federation: is based on WS-Trust and provides some extentions interesting extension that amogn other things, define how to work with passive relaying parties like web browsers. This paper by Microsoft and IBM is a very good introduction to this protocol and the whole flow of messages in the authentication scenario.
If you prefer a single point of introduction instead of jumping among the provided links, I recommend you the book by Cabrera & Kurte called Web Services Architecture and Its specifications (ISBN: 978-0735621626) (watch out! it does not cover all the mentioned protocols but despite of that is a good starting point)

To be continue…