Month: July 2015

On Software Requirements

· Leave a comment ·

There are a couple high level tradeoffs in the requirements specification process. Each tradeoff can be thought as an axis: Specificity (detailed vs vague), Audacity (visionary vs trivial/checkmark), Customer-driven (needs vs wants; with timelines).

It is possible for them to be too detailed – the more detailed and specific the requirements are, the less understandable they are and the less flexible they are in a rapidly changing context. But if the requirements are too vague, then they are likely to be misunderstood or ignored by a development team. This is a case where directly talking to the end users and clear communication between team members to flesh out use cases will help.

Also if the requirements are too visionary then they may appear infeasible to the team.  Showing they are achievable by looking at related products is one solution. Decomposing the target into achievable modules is another. If they are too near-term, then they may appear trivial and fail to excite the team.

Finally the requirements should be well grounded in customer use cases and narrowly stated, rather than inherited as a long list from past successful technical products. This is probably the most important and hardest thing in practice.

Specifying the right amount of detail for development targets that are grounded, challenging and achievable is an important skill.

Another take on this topic is Joel Spolsky’s series on writing painless functional specifications.

SSO, SAML, OAuth, JWT, OpenID

· Leave a comment ·

Web authentication and SSO typically imply that state is maintained on the server to indicate whether the user is logged in or not. The identity provider maintains this state and the identity consumers check this state with the identity provider. The protocol and message format differ in different implementations – SAML, OAuth, OpenID and several others.

SAML is the richest, most flexible auth protocol, but also most complex to implement. It covers the most number of use cases. The security assertions about an identity are captured in an xml format which can be exchanged between providers and consumers over the web.

OAuth is simpler and requires fewer things from the implementer. OAuth 2 has become a vehicle for enterprise use cases like SAML. SDKs for OAuth are available.

OAuth 2 and OpenID both use Json WebToken (JWT) which is a JSON format specification for interoperability.

OpenID Connect is the most open and newest of the three. It reduces  reliance on checking auth state with the identity provider by embedding more information in the JWT and standardizing things like scope to increase interoperability. If officially supports authentication use cases, unlike OAuth2 which is designed for authorization, but is used for pseudo-authentication.

A key consideration when deciding on an implementation is the scalability requirement. Ideally the system is structured to keep the least amount of state (zero) on the server. This is not true of most SSO implementations.

Like a stateless NFS server, based on leases for lock state that can be refreshed, a stateless implementation for SSO is possible (classic NFS has no open, only lookup). The tradeoff is that revocation is not as easy and reporting may need to be handled differently than with a stateful implementation. Here’s a discussion – http://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration

Update. Here’s another discussion which points to some tradeoffs – https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens , basically that this is more useful for SSO and API implementations not simple websites.