What Cross-Domain Single Sign-On implementation best solves my problem?
I have two domains (xy.com & yz.com) which already have their own database of users and are already implementing their user authentications separately. Recently there has been the need to implement CDSSO so that users dont have to log in each time they try to access resources from both domains.
Ideally the CDSSO implementation I hope to use should allow custom implementation of authentication, as I hope to call API's provided by both domains during authentication to confirm a user exists in at least one of the domains user database.
I've been looking at Sun's OpenSSO which seems to provide a means to extend its AMLoginModule class yet this seems to be a long thing and more annoyingly they seem to stick to GlassFish.
I've also considered developing a custom CDSSO to solve our needs. Is this advisable?
Is this achievable using Suns OpenSSO considering the disparate user database as I there will be no need to make use of the User db that OpenSSO requires?
Are there any simpler means of achieving what I intend to achieve?
In addition both applications which exist on the two domains were developed using PHP. How does this have an effect considering Suns OpenSSO is based on Java EE?
Are there any clearly specified steps on implementing OpenSSO and or any other SSO implementations from start to finish?
I suggest you to use simpleSAMLphp in order to deploy an Identity Provider and 2 Service Provider (for each app).
SimpleSAMLphp allows you to select multiple authentication source and is not hard to build your own authsource that consults the 2 databases.
My experience in SAML says that the fact of not consolidating the Identity of the user in 1 unique authsource is a bad idea due several reasons:
* identity conflicts: what happen if you have the same user registered with different mail (if that is the field yoy use to identify the user) and you try to access? You could be logged in different account each time.
* what happen if you add a 3rd service, do you gonna add a 3rd database
* what happen if user change its data in one app, the other gonna be no synched?
* what happen if user uses different passwords?
I recommend you to execute a migration process before adding the SAML support and build a unique database for all your identities and unify the registration/edit profile/password recovery process of both sites in one.
SimpleSAMLphp has good documentation, but I can provide to you any documentation related to the process that I suggested.
Related
I have a user permission system in place where i have a set of permissions within the database, for example
id
Permission
1
POST:CreateBooking
2
GET:AllBookings
And i have another table (junction table) where i put dependent permissions such as
if i want to create a Booking, i need to fetch Package details and so POST:CreateBooking requires the user to also have GET:AllPackages permission.
There's a template system in place as well, where the users can group multiple permissions together and once that template is assigned to any employee, that employee will get THAT set of permissions and it's dependent permissions.
What my nodejs system does is that when user logs in, it fetches all permissions from DB and puts it in a redis set from where on each request, the permission is checked against user id.
Is there any tool from where i can do exactly this but in an intuitive and better way?
I tried keycloak but i don't know how to cover my needs mentioned above.
Thank you
if I'm understanding correctly and trying to generify your scenario, you have a classical situation where:
You have groups which can have multiple permissions assigned;
groups can be created dinamically;
each permission correspond to a specific functionality.
So, implementing the OIDC (Open Id Connect) protocol might fit you needs. As you suggested youself you might be interested in a OpenID provider (do not reinvent the wheel) keycloak is good, you can give a look also to Vault Hashicorp.
So assuming that your backend have an already existing framework to handle security and permissions (eg. Spring Security) you can produce JWT token with the OpenId provider and check throught PreAuthorize claims (permissions) inside the token.
At the end your security layer it's just an annotation you need to insert before your method controller or before you class controller.
Behind the scenes, instead, this is what will happen:
Your user connect to your app;
User insert username and password -> the Open Id provider gives you a JWT
Your Front End app everytime it make a REST req will send also the JWT
The back end controller method called it's under authorization
Given the public keys of the OpenId provider, the validity of the token it's enstablished
If the specific permission claim it's found inside the token, the request can be elaborated else a 403 Forbidden it's returned.
OIDC - as the conceptual model/backdrop to any tool of choice, is certainly a popular/good choice, but as long as you're willing to deal with an element of complexity - the understanding required to implement an OIDC arrangement (- think of it as a possible investment - effort up front with hopefully the rewards tricking-in over time); e.g. OIDC is an ideal choice for supporting SSO (Single Sign On), especially when it comes to supporting/allowing for authentication/login via providers such as Facebook, LinkedIn & Google, etc (- as well as more Corporate OPs (OIDC Providers) including AAD/Azure AD).
Try to first step-back, and consider the possible bigger/future picture, before selecting a tool based upon only your starting/current requirements.
I am trying to use the new authentication system and I cannot find any decent articles/documentation to get what i want. Plenty of stuff out there explaining how the authentication process works out of the box but realistically you will need more.
First of all how do you control which database you store user information? I have read in many place that you can add a connection string. Ok great, but how do you get that connection string to be used by the authentication system?
And how would this work in a web farm, assuming user account information is split across databases with a little piece of logic which decides which database a user should login against?
I have used keystone extensively and it really isnt bad to implement. Its the authentication mechanism of Openstack. Check it out here http://docs.openstack.org/developer/keystone/
To answer your question users would first authenticate with it, receive a token, then they would present their token at any of your servers. If your data is split up, you can configure keystone to only allow access to certain areas of you backend via groups.
Changing the underlying database needs to steps. You have to add the connection string for the database you want to use for Identity. After this you have to change the base constructor call in your DB context to pass your new connection string to the base class (this is your missing step). An example for it is shown in this thread.
For your second question I don't have a good answer, because I haven't used Identity in a multiple DB servers scenario yet.
What are the basic functionality which it provides?
Specifically for the person who has never used asp.net built in stuff.
The MSDN tutorial is confusing me a lot. Claims, OWIN,etc are going above my head.
What I can make out of all this is - The Identity framework helps me to manage my application plus social logins. It handles my cookie,etc.
What if I have just one role in my application - just the plain user?
Should I go for the Identity then or I should implement my own custom thing?
Any help is appreciated.
If you are starting from scratch, build a sample MVC project with individual membership option, which will create the following components for you:
Login module that creates and manages authentication cookies
Simple database to store basic user data (credentials, name)
EF code to interact with the database
This will most likely meet your use case for a user without roles and attributes.
OWIN really has nothing to do with authentication, it is a new spec for building web apps. The login module happens to be implemented according to this spec and it sounds cool, so Microsoft likes to throw this term around a lot.
If you are not planning to have authorization logic in the app, then you don't need to worry about Claims. Claims is another term for user attributes (login, name, roles, permissions). The Claims collection will be populated by the framework, but you most likely won't use it. If you need just the user id/name, the old ASP.NET interfaces are still there to get this data.
As far as implementing your own, I've seen people here ditching the database and EF code, especially if they already have an existing user store. You just need to implement a credential verification logic against your store. You don't want to build your own cookie management, though. Use the login module provided by Microsoft or well established third party systems (SiteMinder, Tivoli, etc.)
Looks at this open source project for a good alternative to ASP.NET Identity.
This is a very well put together tutorial that explains many of these concepts, you can get a free trial to the site to see it.
I'm starting on a project to allow an existing web application to use active directory for authentication but leaving authorization within the application. I want to start off simple so I was thinking a user would type their AD username/password into my existing login form, I would then do an ldap bind against the AD server to authenticate the user.
Once the user is authenticated, I would pull that user from my database which has all the authorization information as to what functions the user can see.
My question is what is the best AD element to store in my table to make the association? In the past I've used username but after looking at some of the elements that AD returns I was wondering if I should use the security ID or GUID or something else?
I've been burned when a username changes like an employee gets married or divorced... so I know that is brittle.
I was targeting windows 2003 AD and above if that makes a difference; this is for a product where some clients have large AD forest and some are small networks.
Storing the SID is the most reliable approach; this is the unique ID that all Microsoft AD things use, security groups, permissions, etc.
If you're building on .Net you should seriously consider .Net 3.5, there's a new namespace System.DirectoryServices.AccountManagement that greatly simplifies code here and gives you nice neat objects to go against.
Unless users share computers, why not use Windows integrated logon? Much easier on the users, easier on yourself as developer, and more secure (one less place a password can be sniffed).
Need I mention that allowing user identities to change is poor corporate security policy? Makes traceability harder, permits some novel attack vectors, and gives you this headache.
As Nick mentions, the SID is a stable identifier, but not something you should ask a user to enter for him/herself!
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.