Showing posts with label Identity. Show all posts
Showing posts with label Identity. Show all posts

Sunday, January 15, 2017

WSO2 IS : How to do Conditional Authentication using Entitlement Policies?

WSO2 Identity Server 3.0 has a brand new feature that allows users to be authenticated based on a set of XACML policies.

Use case - Allow only users with customer-care role to login to Cloud Based Microsoft Dynamic server.

1 - Configure logging into Microsoft Dynamic server using SSO by following this link.

2 -  Make sure you have set the "Enable Authorization" tick in Service Provider > Local & Outbound Authentication Configuration.

3- Then Go to Entilement > Policy Administration in the left hand menu



4 - Select the authn_role_based_policy_template. Edit it to have the Service Provider name as "CRM" (or the name you have given to the Microsoft Dynamic Server.  Change the the role name as "customer-care" and publish it to My PDP.

That is it!

Friday, December 4, 2015

SAML SSO with GoogleApps using WSO2 Identity Server


We are going to be using WSO2 Identity Server as the SAML provider for Google Apps. This is a valid scenario where an Organization's identity provider is an independent third party. Here is the scenario we are going to support.







Setup SAML SSO in your domain by following google documentation. https://support.google.com/a/answer/60224?hl=en

 The Sign-in page URL is in the form of, https://host:port/samlsso. The change password URL is pointed to the portal where employees use to change the password.







At WSO2 Identity Server Side, go to Main->Service Providers->Add. Now add the following configuration.
  • The ACS URL is https://www.google.com/a/test.com/acs
  • Since we have ticked the "Use a domain specific Issuer" above, our issuer is "google.com/a/test.com"
  • NameId format is "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  • Enable Assertion signing (The corresponding certificate has been uploaded in the previous step into GoogleApps)
  • Enable Single Logout and Attribute Profile

Note - test.com needs to be replaced by your actual domain name.



Friday, November 27, 2015

SaaS Identity and Directory Services


For SaaS providers, what are the available mechanisms for integrating with a directory service?

  1. The LDAP can be fronted by an IdP hosted in DMZ that provides authentication and authorisation mechanisms to Cloud services. The authentication/authorisation mechanisms can be via web federation protocols such as SAML/OIDC. This is show in the above figure.

  2. The LDAP (rather a replica of it) can be exposed via "ldaps" (ssl protected ldap) to the external Cloud services

  3. The LDAP itself can be synced to the Cloud services. Technologies like Azure AD Connect can be used to implement this methodology

From 1st to 3rd mechanism, the security/privacy responsibility that lies on the SaaS provider increases.

In order to the 3rd mechanism, the users must trust the SaaS provider to store data and passwords. I believe, any organization will think twice before syncing LDAP with external parties.

So one might ask, hold on, what about online enterprise identity providers? Online identity providers such as OneLogin has obtained certifications to prove that data is private and well protected.  Obtaining such certifications are very expensive, and they needs to be maintained (audits must be done periodically).

The first mechanism can be illustrated as follows.


Wednesday, November 25, 2015

Federation Patterns - Why/How federated authentication only?



Federated authentication (SSO) and Service Provider maintained sign in can co-exist in the system, but this has account management problems. Consider your HR system has the following.


For example, when an employee leaves the organization, it is required to delete him from both places manually. This is error prone.


In order to overcome this problem, it is better if the system can give an option to disable maintaining passwords at their end, when there is an external IdP.
When an organization decides that they want federated authentication only, the system must provide a way to disable local authentication mechanisms. This means,
  • Show only the Identity Provider Sign In option in login screen
  • Forgot password link is not there in system login screen
  • Existing passwords get scrambled
  • Users cannot reset passwords from the their profile
Now comes the interesting question, how is my mobile app going to work? It can be done in One of the two ways.
  • Users can go to profile and generate a pin number for the mobile app
  • Implement SSO for mobile app. Here SAML based SSO is challenging because it is based on browser redirects but Native SSO support is available based on OIDC (Open ID Connect ) and OAuth

Wednesday, August 26, 2015

OAuth as a Service

WSO2 API Cloud brings you OAuth as a Service. If you are a person who,
  • Has a service/API behind a firewall that needs to be opened up to the public
  • Has ability to introduce a firewall rule
Then this blog post will explain, what you need to do.

In addition to OAuth protection, here is what you get after using WSO2 API Cloud,
  1. Advertising to public in your own portal
  2. Public developers will be able to get OAuth consumer secret/key from portal and call your API
  3. You will be able to monitor API statistics such as - no of calls per service, who is calling the service
  4. Throttle the API as required
  5. Finally charge the API when that feature is added

High level architecture


 

Now you can instantly enable OAuth to your API. Steps,

1) Firstly, protect your API. If it is a JaxRS service protect using HTTP BasicAuth. If it is a SOAP service protect using UsernameToken. In step 3 you will see why we need to protect it.

2) Then get an account in http://cloud.wso2.com protect it using OAuth. Here is the tutorial on how to do it.





Now you have the API in a public portal.

3) Now contact send an email to cloud@wso2.com to get an IP, in-order to add a firewall rule enable this IP to talk to your service. We need to protect the service using username/password to avoid unauthorised access, because there could be an attack where unauthorised party trying to call the same services, if it is not protected.

Now you have implemented the architecture mentioned above.


Tuesday, February 23, 2010