identity patterns and anit-patterns in real world web services
DESCRIPTION
Identity patterns and anit-patterns in real world web services @ Apache Asia Roadshow 2009 ~ ColomboTRANSCRIPT
Identity patterns & anti-patterns in real world web services
~ By Prabath Siriwardena, WSO2
Proof of identity
Something you know…
Something you have…
Something you are…
Multifactor Authentication
Anyone can access my Service
WSDL
WSDL
WSDL
WSDL
WSDL
WSDL
Transport Level SecurityVs
Message Level Security
Transport Level Security
Message Level Security
<wsse:UsernameToken wsu:Id="Example-1"><wsse:Username> ... </wsse:Username><wsse:Password Type="..."> ... </wsse:Password><wsse:Nonce EncodingType="..."> ... </wsse:Nonce><wsu:Created> ... </wsu:Created>
</wsse:UsernameToken>
BasicAuth with Transport Level Security
Direct Authentication Pattern
Problem :
How to avoid anonymous users accessing a web service
Direct Authentication Pattern
Solution :
The web service acts as an authentication service to validate credentials from the client.
Direct Authentication Pattern
Implementation(s) :
UsernameToken with WSSEBasicAuth with TLS
Exception Shielding Pattern
Problem :
Exception data output by a service containing implementation details could compromise the security of the service
Exception Shielding Pattern
Solution :
Potentially unsafe exception data is "sanitized" by replacing it with exception data that is safe by design before it is made available to consumers
Users OUT SIDE Our Domain Need ACCESS
Direct Authentication needs us to maintain user credentials internally
We don’t have the credential of external
users
Direct Authentication doesn’t solve our problem
Can’t we delegate Authentication to the External Domain itself
WS-TRUST
Brokered Authentication Pattern
Problem :
How to avoid anonymous users accessing a web service and give access to users outside our domain, where we don’t have the users’ credentials to validate
Brokered Authentication Pattern
Solution :
Delegate authentication to a third party who knows to validate user credentials and the service trusts the assertions provided by that particular third party
Brokered Authentication Pattern
Implementation(s) :
WS-TrustOpenID, Information Cards, OAuth
How do we know the legitimacy of the third party
Security Token Service ?
Data Origin Authentication Pattern
Problem :
How do we prevent an attacker from manipulating messages in transit between a client and a web service.
Data Origin Authentication Pattern
Solution :
Validate message integrity and non-repudiation with message signature
Our services access downstreamresources with the
authenticated user’s credentials
This could bring security risks –and make down stream resources
vulnerable to attacks
How about controlling user access to the down stream resources
Service acts as the client –with service’s credentials
Trusted Sub System Pattern
Problem :
A consumer that accesses backend resources of a service directly can compromise the integrity of the resources and can further lead to undesirable form of implementation coupling.
Trusted Sub System Pattern
Solution :
The service is designed to use it’s own credentials for authentication and authorization with backend resources on behalf of the consumers
Patterns @ Work…
Message Interceptor Gateway Pattern
Problem :
Different services deployed could have different security policies and a security vulnerability of the weakest service could be exploited to create loop holes in entire system.
Message Interceptor Gateway Pattern
Solution :
Provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages.
Thank You…!!!