AFSecurity: Identy Federation - Trends and Technologies

Identy Federation - Trends and Technologies
AFSecurity 2008-12-11
UNIK, Kjeller

http://wiki.unik.no/index.php/Infosec/AFSecurity

1. Solutions and plans for ID management in the Norwegian public sector - Steinar Skagemo, DIFI

ID solutions:

• BuyPass card: Level 3-4
  
• MinID: Level 3. Subproject#1-2008 (SMS OTP).
  
• BankID (OTP, server stored): Level 3-4
• National ID card: Level 4. Subproject#3-2010. Tenders: Buypass, BankID (have frameworks corresponding to L4).
  

Certificate traffic hub (Samtrafikknav for sertifikater): Subproject#2-2009. FEIDE.
E-ID support organisation: Subproject#4.
From SSN to self chosen User ID - improvement.

Level3: No personal oppmøte.
Level4: Personal oppmøte.

Service providers:

• FIN, SKD
• Helse
• Kart, Tinglysing
• Brreg, Altinn
• Lånekassen

Sharing of attributes is included in SAML2.

NN: Can I choose preferred authentication method and whether to require re-authentiction instead of SSO?
SS: Thanks for question, will take note. (AR: Implement with attributes UserPreferredAuthenticationMethod and UserPrefersReauthentication.)

If session hijacking is a problem, then require re-authentication.
If session hijacking is not a problem, then prefer SSO.

ZI: Provisioning? (How to get devices out to users)
SS: PIN -> mail. Self registration.

PT: Use national E-ID for private sector?
SS: Not decided yet. (AR: Could be done for same or higher security levels)

T.Gulbrandsen, IBM: Responsibility? (lack of that killed PKI around 2000).

2. ID federation and user control - Jonathan Scudder, Sun / UNIK / Uni Oslo

2.1 Intro

Federation = union of states united by a central (federal) government. Examples: USA, Schengen.
Identity Federation = SSO / Web / shared attributes / trust+info accross organizations / standards-based. Examples: MinID, Altinn, FEIDE.

Circle of Trust - Principal (Customer / Employee / Game user), Web Service Provider, Web-Service Service Provider.

1-2-3 SAML2 is the preferred flow:
1. User request to Service Provider (SP). SP checks if user has local session, if not, user is redirected to ID Provider (IDP). IDP returns login page.
2. User enters credentials, sends to IDP. IDP authenticates user and returns redirect page (containing no secrets) to SP through User.
3. SP calls IDP web service to verify that user is authenticated and to get additional attributes, and return Service Provider's service page.

ZI: How does user authenticate Service Provider and ID Provider?
AJ: Not included in SAML2. Does SAML help against Phishing? (e.g. a fake IDP or IDP MITM). No,it's done on the transport layer (SSL). Phishing can be solved by Pet name system. Other options: Use Firefox Trust Bar.

Phishing: paypa1.com looks almost like paypal.com, certificate looks OK. (AR: DNBN0R.com)

Demo:
1. User selects Federation (Bighotels, Government Norway, FlyMe), then
2. User selects ervice (Defense, Tax office, Pension Fund)
3. User enters SSN and authenticates according to service level
4. User get access.

UNIK is an OASIS member.
SAML or other standards e.g. ISO (WS-FED, Shiboleth, ID-FF)? SAML2.

2.2 Federated ID's:

MinID:
- protetcts MyPage (Min Side)
- PIN
- Government-to-cititzen

Altinn:
- various authentication methods
- government-to-business (primarily)

FEIDE:
- educational federation
- distributed authentication

Sikkerhetsportalen (BBS): Test system using BankID/Buypass worked. Payment agreements (who pays - user, SP?) Risk agreements? Failed.
AJ: Altinn lacks registration framework.

2.3 Who knows what?

IDP: Holds most info. business motivation.
SP: Holds local details and important attributes

2.4 ID Dashboard

User's access to manage Federated ID's
- Federations
  - IDP's
- SP's
- Legal stuff
- Auto create account enabled?
- Attributes
- Permanently linked?
- Do you trust entity?
- Opt-out?


OpenID: Auth for social networks. Not for L4.

Next meeting: 2009-01-21. Speakers: IBM.

Lazy dog for releasing with Maven and Subversion

Lazy dog for releasing with Maven and Subversion

Introduction

We release software with where new features are added to 1.0.0, 1.1.0, 1.2.0, and so on. Maintenance releases of 1.0.0 are numbered 1.0.1, 1.0.2, and so on.

We use the branch-before-release pattern with the following structure.

Directory structure

trunk/

branches/

tags/

where development is done on trunk with the following standard Maven structure:

trunk/pom.xml

trunk/src

trunk/target

After a branch of trunk 1.0-SNAPSHOT, the trunk/ structure is created in directory branches:

branches/1.0.x

After a release in the branch directory, the structure is created in directory tags:

tags/1.0.0

Version numbers in pom.xml

When creating branch 1.0 from trunk, we get the following versions in pom.xml:
* trunk: 1.0-SNAPSHOT → 1.1-SNAPSHOT
* branch: 1.0-SNAPSHOT

where trunk will be the next development version.

When creating the first maintenance release 1.0.1 on branch 1.0, we get the following versions in pom.xml:

* branch 1.0.0-SNAPSHOT -> 1.0.1-SNAPSHOT

When creating release on branch 1.0 with mvn release:prepare, we supply the following version numbers:

• release version 1.0.0 for the first release,
• release version 1.0.1 for the first maintenance, ... and so on.

Steps to branch and release

Assume that you have set up Maven pom.xml with <scm> tag, a work directory named work and SVNURL is the URL to the source code repository. Optionally you have an <distributionManagement> tag that mvn deploy uses to put its artifacts after a build.

Run the following steps to create a release,

1 Create branch

(e.g trunk pom.xml version 1.0-SNAPSHOT → branch 1.0-SNAPSHOT, branch name=1.0.x)

1. cd work 
2. svn co SVNURL/trunk 
3. cd trunk
4. mvn release:branch -DbranchName=1.0.x -DscmCommentPrefix='[AR-10 create branch 1.0.x and trunk version 1.1]' -DautoVersionSubmodule=true --batch-mode 
1. To test, run with -DdryRun=true instead of --batch-mode, then
1. Maven will prompt: What is the working copy version for ...? Enter: 1.1-SNAPSHOT
2. clean up by running: mvn release:clean; mvn clean; svn status;
   
3. Additional cleanup: svn status | awk '{print $2}' | xargs rm
2. Add -Dmaven.test.skip=true speeds up the process - after all, it's an administrative command (copy from one SVN location from trunk to branch, change SCM in branch ( step version in pom.xml's and change SCM location... :-)
3. If you get "Cannot commit - the source is from another location":
1. run svn info, it should be equal to <scm> in pom.xml. For example, I had checked out from url: svn+ssh://arr@server.com, and svn+ssh://server.com in pom.xml's <scm>.
2. Workaround: check out from the URL specified in the pom.xml's <scm>.
   

2 Create release tag from branch

(e.g branch pom.xml has version=1.0[.0]-SNAPSHOT → releaseVersion=1.0.0)

5. cd work

6. svn co SVNURL/branches

7. cd branches/1.0.x

8. mvn release:clean release:prepare -Dtag=1.0.0 -DreleaseVersion=1.0.0 -DscmCommentPrefix='[AR-10 create release 1.0.0 on branch 1.0.x]' -DautoVersionSubmodule=true ---batch-mode

   1. Test as for Create branch.If you omit --batch-mode, then Maven will prompt for:

   1. What is the release version for...? Enter: 1.0.0
   2. What is the development version for ...? Enter: 1.0.1-SNAPSHOT
      
   2. If build/commit fails, you get "Unable to download the artifact" for task-segment: [clean, verify] (we get this for an artifact msec-bankidclient):
   1. Go to directory branches/1.0.x (that contains files to be commited for tag 1.0.0).
      
   1. Copy to tags/1.0.0 by running: svn cp SVNURL/branches/1.0.x SVNURL/tags/1.0.0
   2. Step the version number from 1.0.0 to 1.0.1-SNAPSHOT
   1. find . -name 'pom.xml' -exec perl -i -pne 's#<version>1.0.0</version>#<version>1.0.1-SNAPSHOT</version>#' {} \;
      
   3. Change <scm> from tags/1.0.0 to branches/1.0
   1.  perl -i -npe 's#tags/1.0.0#branches/1.0.x#' pom.xml
      
   4. Commit to branch 1.0.x
   1. svn commit -m 'AR-10 stepped version and scm location.'
      

3 Build release from tag

(e.g. tag 1.0.0)

9. cd work

10. svn co SVNURL/tags/1.0.0

11. cd tags/1.0.0

12. mvn clean install [deploy site-deploy]

1. If deploy prompts for password, you can <distributionManagement>add server ID, username and password
   

If svn commit goes wrong inside an mvn release:* command, run:

mvn release:rollback to revert committed changes, before mvn release:clean.

Improvements

Can be automated:

• branchName is version from trunk/pom.xml minus -SNAPSHOT

• releaseVersion is ${branchName} + . + last version from pom.xml

References

• http://maven.apache.org/plugins/maven-release-plugin

• http://jlorenzen.blogspot.com/2007/09/how-to-create-release-using-maven2.html

• http://www.christophkiehl.com/automatically-create-releases-and-maintenance-branches-with-maven

2008-12-06 Arne Riiber - Initial version
2008-12-09 Arne Riiber - Updated with fixes for cases when plugin fails. Set branch name to 1.0.x.

Test Driven Development - 2 hour Crash Course with Robert C. Martin [Object Mentor]

Systek, IT Fornebu, 2008-04-08

Notes from the meeting

Tools: IDE (IntelliJ), Junit, Fitness. Platform: MAC.

We were introduced to rules of Bowling: Game of 10 x 2 frames.

Requirement: Write program to register rolls of bowling pins, and compute final score.

We created UML diagram with classes: Game, Roll, Frame, TenthFrame. The diagram is a rough design guide. In our case, the UML diagram showed up to have more classes than required by the implementation. By using test driven development, we created the simplest possible solution, and tests to prove that it works.

Rules of development:

Iterate:

1. Write the simplest possible unit test method. Compile it. Run it – should fail.

2. Write the simplest possible code method causing the test to pass.

3. Advance to the next most simple test, goto step 1.

Agile development: principles

• Inner circle: key elements: Unit test – Refactoring

• Outer circle: Acceptance test

• Software is made soft, i.e. it can be changed: Your loose the fear for changing the code because instant test will prove that it still works or breaks

• User story – feature to be implemented in one iteration, decided by manager and development team

• User story delivery rate – ca. 45/week (average, 40-49)

• User Stories left: Start w/500, reduced w/45 for each week

• Iteration cycle: 1 week (best), some use 2 weeks, other 3 weeks – too long

• Get addicted to “Push the button” in Unit test and Acceptance test to display green success bar – similar to lab experiment with mouse pushing the button to get happiness stimulus electronically into its brain

Rules

1. Do not write a single code line before the first test for the code has been written.

2. DRY – Do Not Repeat yourself, neither in test or production code

3. Comments – feel shy when writing them, they tend to rotten. Instead, write self explaining code.

   1. Do not separate code segments with comments – instead, make them functions.

4. Refactor continiously.

5. A function or method named X should have body size of 1-10 lines.

6. Functions should have from 0 to 3 arguments (best to worse).

7. For functions with 4 args, args should be converted to objects (e.g. draw(x0,y0,x1,y1) → draw(Rectangle).

8. A class should have no more than ca. 10-12 variables.

9. Instead of f(boolean a), create fTrue() and fFalse().

10. Never return null, since the caller then should create an if statement and sometimes fails to do this, causing bugs.

11. Code should be readable – replace score += rolls[i] + rolls[i+1] with score += firstBall(i)

12. Unit test the formal (public) API of a class.

Key selling points

• A system with 45K lines of code had 1/3 test code. Test code is similar to accounting credit and debet – balance of 0 shows it is probably not broken.

• The defect rate goes down with a factor of 10 for TDD code.

• Production efficiency goes like this: Very high in the beginning, then slower. Management put on more people and productivity immediately goes some up, then decays.

• A system under refactoring is stable at all times – all tests pass

• QA people write Acceptance tests in Fitness, developers executes these tests.

Ruby:

1. Dynamic types – the caller does not need to know the type and methods of the called object. TDD enables hard testing of objects with dynamic types, type that the compiler detects in static typed languages (like Java).

2. Closures – a code block can be passed around as an object and get methods added

3. Size – 1/5 size of Java code.

AR comments:

The technique seems to stem from Smalltalk, and can be used on static and dynamic languages. There were no getters or setters (getX(), setX(x)), like used to in Java. Instead, the focus was on writing as simple as possible (which is good). There was no focus on public, protected and private scope. The technique makes it efficient to locate and fix errors at any time, and to change structure without changing behaviour. This in turn makes maintenance of production code easy – you can change it, because you have lost the fear of introducing unknown bugs caused by the change. Encap would benefit from using this technique to a much larger degree than what is present today.