SSO Shibolleth

Shibolleth is a popular open source single signed on (SSO) framework. Using SSO, we avoid too many password accounts for different applications that will increase the phishing risk, ear drop risk and revocation problem (you need to cancel/change all the password accounts in all applications).

Other features of Shibolleth:

• federated e.g. you can use a national-wide IdP such as SURFnet in the Netherlands and then SURFnet will communicate with your local (university) IdP to authenticate you.
• the application (via SP) can obtain user metadata (e.g. employeeID, email) from IdP
• SP & IdP are communicated using standard SAML format

Shibolleth consists of 2 parts: the Service Provider (SP) an Apache-module that resides next to your web application in the Apache web server and the Identity Provider (IdP) server that authenticates  the user based on authentication source e.g. LDAP, database, password files, SAML security provider (e.g. Aselect), OAuth security provider such as Google, etc. The SP consists of shibd daemon and shib apache module.

The flow of Shibolleth is as follows:

1. The user browse a web application. In the apache config, this web application is declared as protected using Shibolleth.

2. The user will be redirect to the IdP for authentication. The IdP will use an authentication source (e.g. LDAP) to authenticate the user.

3. The IdP  will send the security assertion to the SP (via client session cookie).

4. The SP can obtain user metadata (e.g. employeeID, email) from the IdP.
5. The SP grants access to the application

SSO for webservices

An interesting idea about using SSO Shibolleth for web service:

http://predic8.com/shibboleth-web-services-sso-en.htm

Since Oracle OSB has functionality to access http header, so it's possible to use Shibolleth SSO in OSB web services proxies.

  

Links

Exercise SP install & config  to connect to Dutch SURFnet IdP using Shibolleth:

https://wiki.surfnetlabs.nl/display/surfconextdev/My+First+SP+-+Shibboleth

Shibolleth security checklist:

https://wiki.surfnetlabs.nl/display/surfconextdev/Shibboleth+SP+security+checklist

Want to establish your own IdP? SimpleSAML is one of the easy framework:

Install http://simplesamlphp.org/docs/1.5/simplesamlphp-install

IdP config http://simplesamlphp.org/docs/1.4/simplesamlphp-idp

Source: Steve's blogs http://soa-java.blogspot.com/

Any comments are welcome :)

---

OAuth

If you use social media (e.g. facebook, twitter) it's likely that you've used OAuth. OAuth works also for devices, e.g. my TV uses OAuth to let me access my Youtube account.

Usages:

• Delegated authorization e.g. a (web) application (the client / resource consumer) want to access a user data  in a resource provider (e.g. google calendar or facebook photos/friends), the application rely on user permission (authorisation) using an authorization server (e.g. facebook, google)  to get access to user's data.
• OpenID, which is build on top of OAuth protocol, provides single sign on / (federated) delegated authentication.

Advantages:

• To avoid too many password accounts for different applications that will increase the phishing risk, ear drop risk and revocation problem (you need to cancel/change all the password accounts in all applications)
• To avoid sharing password to resource providers, only the security provider (e.g. google) registers your password
• To standardize different (delegated) authorization methods from different vendors. At this moment in practice there are still minor differences between different vendor implementations, but the distances between them are getting smaller and generic APIs (e.g. Scribe) that adapt to different vendors are available.

Best practice

• the auth token is sent with http header instead of URL GET parameters: less obvious, to avoid the token being cached/logged as url entries
• use SSL to avoid the attackers steal the token
• limit the token lifespan (if you revoke the token it will not last too long)
• use random salt to prevent CSRF attack.
• manage user experience: tell user what happens "e.g. This application needs your approval to use this resource. We will redirect you to an authorisation server (e.g. google) so that you can give permission."

Protocol:  the web server application flow (a.k.a. the 3 legged flow)

This is the strongest OAuth protocol, to avoid the client browser (e.g. malicious javascript) to catch the access token by using intermediately autho code (which later is being exchanged for an access token via server to server call that safer than browser to server call).

First the client application has to register to the autho server / oauth security provider (e.g. google) to establish clientID & password.

The flow:

1. The application makes oauth request to the the authorisation server with parameters: clientid (from the client application registration), resorce scope (e.g. google calendar), redirect url (where the user will be returned after they approve the access) and other parameters such as state (random salt against CSRF) and access_type ('offline' for the 3 legged flow). The user has to login and then gives permission/authorisation to the application via authorisation server web interface. The authorisation server then return the user (& send the intermediate code) to the redirect url.

2. The client application then can exchange the intermediate code for an access token.

3. The application then can access the user data in the resource provider using access token. The resource provider will validate the access token. The validation process is not defined in the standard, but for example some OAuth implementation provide API in the OAuth server where the resource provider can exchange the token with user's id & scope information and then compare this result with the resource provider's own ACL.

4. Optional: in some scenarios the access token will be expired, the application need to obtain a new access token using refresh token.

Other protocols:         

• client flow (a.k.a. the 2 legged flow) : the client received the access token directly (instead of have to exchange the intermediate code.) This approach is less secure (since the access token is exposed to  the client browser, so for example a malicious javascript can steal it) but good enough for many non critical applications (e.g. invitations for photos viewer).
• password flow: use password to be exchanged with an token. This approach is less secure (the application/resource provider will know your password) but can be used for login to trusted applications inside a company (e.g. webmail, CRM).
•  client credential flow: use the client credential from the client registration. This typically is used for internal applications or trusted cloud integration e.g. salesforce CRM to your company.
•  devices flow: for mobile devices, smartphones, TV.

Links to tools/libraries:

• Google playground to try/understand OAuth protocol and its http messages: https://developers.google.com/oauthplayground/
• Google API lib:  https://developers.google.com/accounts/docs/OAuth2
• Scribe (a single oauth client framework for different APIs such as google, twitter, linkedin, facebook)   https://github.com/fernandezpablo85/scribe-java
• OpenConext: a complete OAuth API (authorization server, resource provider, consumer client) https://github.com/OpenConextApps/apis#apis-
• Oauth provider & consumer using Spring http://spring-security-oauth.codehaus.org/tutorial.html
• List of OAuth libs: http://oauth.net/code/
• OAuth consumer example to connect to the Dutch Surfnet https://wiki.surfnetlabs.nl/display/surfconextdev/OAuth+example+in+Java+%281%29
• Demo OAuth for devices (e.g. TV) http://oauth-device-demo.appspot.com/

OSB

Oracle OSB has functionality to access http header, so it's possible to use OAuth/OpenID with OSB web services for delegated authorization/SSO.

Recommended reading:

How to Secure Your OAuth Implementation
http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation

Source: Steve's blogs http://soa-java.blogspot.com/

Any comments are welcome :)

---

References:

Getting Started with OAuth 2.0

Programming Social Applications:

Android Simulator : simple up and running...

You don't have a smartphone yet but you're curious about how your website looks like in a smartphone?

Cost: free
Time needed: 5 minutes
Steps:
1. download and install the Android development SDK: http://developer.android.com/sdk/index.html
2. create an Android Virtual Device (AVD) profile: startmenu>manage ACD>create an AVD (e.g. Android 2.3.3 HVGA)
3. run the emulator: e.g. emulator -avd name-of-your-avd

---

Source: Steve's blogs http://soa-java.blogspot.com/

Any comments are welcome :)

Mobile web development

Why mobile webs are different
You need to adapt your web application since the usability of mobile usage is different compared to the desktop:
• smaller screen size (e.g. 320x480)
• vast variations of browsers & platforms (each with different limitations & compatibilities e.g. some doesn't support javascript yet)
• competing attentions / multitasking users (e.g. the user may use the mobile while waiting for a bus or talking to friends), this leads to more distractability and shorter session (3 min in average instead of 10 min average of desktop users).
• different input devices (e.g. multitouch & virtual keyboard via touch screen instead of desktop keyboard & mouse)

Design strategies
• define user's goals and how they can accomplish their goal in your web with minimum efforts (i.e. minimum clicks/inputs)
• prioritize the features of the desktop version of your web, implement only the top 20% in your mobile version

Usability tips
Simplicity
• implement only 20% of the features of your desktop web application
• minimize user efforts & user inputs, try to infer the context from history/cookies, geolocation, IP address
• no more than 3 clicks (or pages) depth
• limit the main navigation to 4 links, limit the total links in a page to 10
• minimize text, use short/simple words
• to the point, no welcome screen
• limit the bandwidth: simple image, don't use text-image. The bigger the bandwidth, the more users have to pay & the slower your service is.

Layout
• avoid horizontal scrolling
• avoid multi columns
• use all area, 100% width (don't use side menu, side advertisements etc)
• use fluid layout instead of fixed layout

General tips
• always provide a link to the desktop version
• the most used features at the top (e.g. login in a bank service, search in a library service)
• provide enough space (min 20px) for clickable elements and links, since finger touches need more space than using a mouse
• use background colours to separate sections
• use a list instead of a table

Beside these, many of the desktop UI usability rules are still apply in the mobile world, such as visual consistency, legible fonts, clear structure, consistent alignments, etc

Device awareness and content adaptation
A common approach to handle the variations of mobile browsers/platforms is
by grouping according to device/browser capabilities (the groups don't need to be mutually exclusive) for example based on screen resolution, portrait/landscape orientation support, javascript/ajax support, geolocation support, markup languages (old wml,xhtml-mp,html5).

Starting with a basic version of your web (e.g. a plain html without css & javascript), create a different version for each group (e.g. different screen resolution) using different css and technologies (javascript, geolocation, etc).

Your web application needs to aware about the capabilities of the client browser/device and then adapts the content according to which group this device falls to. So first we need to know which browser/device the client uses, using http request header information, for example an (rather old) iphone:

User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X;
en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1
Mobile/5H11 Safari/525.20
Accept: text/xml,application/xml,application/xhtml+xml,


Then using device libraries (e.g. WURFL) to get the list of device/browser capabilities (screen size, javascript/ajax support, etc).

The weakness of this approach is that you need to maintain several versions of your code (e.g. iphone4.css, iphone3.css, android23.css, vintagemobile.css, ....). The mobile/device list is changing fast, you need to keep up with this (and hopefully also the maintainers of the device library you use). The information in the request header & the device libraries may not be accurate. That why it's recommended to limit the number of groups as minimum as possible.

An example of comparison of a desktop and mobile website
Amazon is one of the most progressive dot.com company, we can learn by observing their design. This is the desktop version:


This is the mobile version (Android simulator, 320x480):

The mobile version has
• much less features than the desktop version
• less text, less images
• list (for links)
• one column
• the most important features in the top of the pages (the shopping cart and the search.)

In the future I will discuss how to implement geolocation mobile web to determine in which building a student is located. Based on this, we provide contextual information to the student for example about the course room/schedule, computer labs availability, the locations of other students from the same course/study-year.

Source: Steve's blogs http://soa-java.blogspot.com/

Any comments are welcome :)

---

References:
Programming the Mobile Web


Beginning Smartphone Web Development


The UI snapshot examples are the courtesy of www.amazon.com

Learning the basic principles of UI / web design

If you're already savvy with the technical sides of web sites (html, javascript, css, jsp) but you still feel awkward with the design sides, then you are not the only one. I was in this situation when I had to build a web application from scratch and I had only 2 days to learn web design principles. Thanks God finally all the shareholders were happy with the results. The user panels voted my design better than a design from a professional designer.

So I'd like to share with you which books that I read in 2 days to learn web design:

The Non-Designer's Web Book
Discuss the CRAP (Contrast, Repetition, Alignment, Proximity) design principles. These principles apply also for print designs/ desktop publishing, which is also my hobby. Also contains some examples of good & bad designs and practical suggestions (e.g. avoid aliasing in the images, use sans-serif fonts etc).

---

Don't Make Me Think
Discuss usability principles:
• be straightforward as possible (such that the users doesn't have to think)
• users scan the web instead of read
• users don't make optimal choices, they don't read all the information, they just guess and satisfice
• users don't read explanations
• if the users find something works they stick to it (e.g. people used to the menu layout in common Windows application), avoid surprise

Also some design principles:
• clear visual hierarchy/structure
• clearly defined areas (e.g. navigation menu, content etc)
• conventions (e.g. colour scheme)
• make it obvious what's clickable
• minimize noise / minimize items in your web

---

Web Design for Developers
A book from the pragmatic programmer series. For developers who have never built a website. contains choosing colors & fonts, mock design, photoshops, how to apply css.

---

Web Design in a Nutshell
A classic book, which I read years ago. Discusses basic factors which affect your design such as screen resolution, browser, flexible vs fixed-width layout. Also contains references for (x)html, css, image formats, etc.

---

Please leave comments if you know any interesting books to learn web / UI design.

In near future I will write blogs about web design for mobile devices, so stay tuned!