Priyar's Rantings

Brokered authentication: X.509 PKI

prudradas — Mon, 24 Aug 2009 14:04:49 +0000

Using brokered authentication with X.509 issued by a certificate authority in a PKI to verify the credentials presented by the requesting app.
The client app attaches credentials to the request message and digitally signs the message with the client’s private key. When the service receives the message it uses the public key which is included in the X.509 cert to validate the signature. Additional validation maybe be required to ensure that the X.509 certificate has not expired and was issued by a CA that the service trusts.

Participants
Brokered authentication with X.509 certificates issued by a certificate authority in a
PKI involves the following participants:
● Certificate authority (CA). A CA is an authentication broker that is responsible for
authenticating clients and issuing valid X.509 certificates.
● Certificate store. This is where the X.509 certificates are located.
● Client. The client accesses the Web service. The client provides the credentials for
authentication during the request to the Web service.
● Service. The service is the Web service that requires authentication of a client prior
to authorizing the client.

Process:
CA issues the X.509 certificate
After the X.509 cert is issued local repos such as a machine cert store are used to store info about the X.509 cert.

1. The client sends a message to the service. The message includes the client’s credentials, signed with the private key that is paired with the public key in the client’s X.509 cert. The client can also attach the X.509 cet to the message. If the X.5009 cert is not attached the client attaches a cert identifier to the request message.
2. The service validates the cert, uses the public key in the client’s cert to verify the clients signature.

Patterns on Webservice security – Brokered authentication

prudradas — Mon, 24 Aug 2009 13:06:14 +0000

Brokered authentication:
The web service requires the application to present credentials for authentication so that additional controls such as authorization and auditing can be implemented
Forces:
The client accesses additional services which results in the need for a single sign on soln.
The client and the web service do not trust each other.
The web service and identity store do not trust each other.
Solution
Use brokered authentication where the web service validates the credentials. An authentication broker issuses the security token. The client presents credentials to the web service

1. The client submits an authentication request to the authentication broker.
2. The authentication broker contacts the identity store to validate the client’s
credentials.
3. The authentication broker responds to the client, and if authentication is
successful, it issues a security token. The client can use the security token to
authenticate with the service. The security token can be used by the client for a
period of time that is defined by the authentication broker. The client can then use
the issued security token to authenticate requests to the service throughout the
lifetime of the token.
4. A request message is sent to the service; it contains the security token that is issued
by the authentication broker.
5. The service authenticates the request by validating the security token that was sent
with the message.
6. The service returns the response to the client.

Common
examples of an authentication broker include the following:
● X.509 PKI
● Kerberos protocol
● Web Service Security Token Service (STS)

Digital certificates and WCF services – Solution 1 – User token in SSL

prudradas — Fri, 21 Aug 2009 13:51:46 +0000

http://www.theserverside.net/tt/articles/showarticle.tss?id=SecuringWCFService

WS*-Security standars – WS-Trust and WS-SecureConversation .
Usertoken thre SSL
——————-

Configure IIS and the virtual directory security where this service is hosted to have HTTPS/SSL.
If I do not do this, WCF will barf up an exception — something to the effect of complaining that the Directory Security\Secure Communications in IIS is not set up properly.

On the client side the channel needs the username and password credentials

Awesome Failure story for codinghorror

prudradas — Fri, 21 Aug 2009 12:59:47 +0000

http://www.codinghorror.com/blog/archives/001297.html

Social innovation perspectives:

http://socialinnovationperspectives.blogspot.com/

Rest-ful Services and SOA architecture and WCF links

prudradas — Tue, 18 Aug 2009 15:11:40 +0000

http://www.xfront.com/REST-Web-Services.html

http://haacked.com/archive/2009/08/17/rest-for-mvc.aspx

http://msdn.microsoft.com/en-us/library/ms734712.aspx – WCF Tutorial
http://msdn.microsoft.com/en-us/library/ms733766.aspx – WCF hosting thru IIS

http://www.c-sharpcorner.com/UploadFile/SunilBabuYLV/WCF4Beginners.aspx

Day 3 – SOA and thoughts

prudradas — Tue, 18 Aug 2009 00:32:30 +0000

Some websites I need to capture

http://www.e-booksdirectory.com/details.php?ebook=1066

http://www.joelonsoftware.com/

http://thedailywtf.com/

http://stackoverflow.com/questions/6327/what-are-your-programming-exercises

http://www.codinghorror.com/blog/archives/000781.html

http://itasoftware.com/careers/SolveThisWorkHerePuzzles.html

http://codekata.pragprog.com/

http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata

Day 2 in Patterns and principles

prudradas — Mon, 17 Aug 2009 03:43:36 +0000

Dependency inversion principle:
High level modules should not be dependent on low level modules. They should be dependent on abstractions
Abstractions should not be dependent on details. Details should be dependent on abstractions.

Ownership inversion – Client will package interface for server. Server module implements interface.

Interface Segregation principle:
Clients should not be forced to depend on methods they do not use

Exercises for design principles

Software Patterns

prudradas — Sun, 16 Aug 2009 01:38:06 +0000

Software Patterns:
Single Responsibility principle – A class should be modified for a single reason
OCP Principle – A class is open for extension but closed for modification – Strategy pattern & Template Method patterns

OCP thru Strategy pattern – Achieved through abstractions.
Client uses server. If client needs to use new server object then the client class will have to be modified to use a new server object instance
Instead client & server use an abstract class called ClientInterface that represents a bound set of behaviors. Client and Server inherit from the ClientInterface abstract class. Client objects will use Server objects. Extension in behavior is achieved through inherited classes.

OCP thru Template Method pattern – Achieved through abstractions
Policy template implemented through an abstract class and classes that inherit from policy template will extend the implementation.

Liskov Substitution principle:
Subtypes must be substitutable for their base type.
Models can’t be validated in isolation
ISA is about behavior
Design by contract – The authoer of a class states the contract for that class. The contract is specified by preconditions and postconditions for each method.

Books to read for work

prudradas — Sun, 16 Aug 2009 01:00:32 +0000

http://www.jameskovacs.com/blog/TheBookshelf.aspx

Day 1 – Prep for Tech upgrade

prudradas — Sun, 16 Aug 2009 00:14:09 +0000

Finally finished up installing vpn access, skype and currently installing VS 2010 Beta on my machine.

My mission:
To learn how to use VS 2010 Beta efficiently
Learn ASP.NET MVC
Entity Framework
SOA architecture

TO-DO:
Resharper for VS 2010