TL;DR: I'd like to make a Moodle installation and an ASP.NET Identity-based site share authentication. If they have a single login page, so much the better, but logging in to one should automatically log into the other; logout should also be shared.
I have a Moodle installation (M) at www.example.com/moodle, and another website (O) at www.example.com.
O is written using .NET 4.5.2 and has areas that require authentication to access, managed using ASP.NET Identity 2.1 with a custom user model. This model is not particularly sophisticated. It is essentially the out-of-the-box model, but with integer IDs rather than GUIDs.
M is version 2.6, with intentions to upgrade to the latest version (currently 3.1) in the near future.
Both are accessible via the public Internet; there is no requirement to be on a private network to access them.
I know of no plans to move either M or O onto a different domain. However, if one or both was to move, I imagine they would move to a subdomain of example.com.
I would like to create a single-sign-on system, allowing a login for M to also log the user into O. As it stands, I am using the external database authentication plugin for Moodle, with M referring to the database for O. While this works, it does require the user to log in twice. I would like to set it up so that logging in to either M or O will also log the user in to the other site.
I am able to create matching hashes from PHP and .NET code. Unless it is particularly relevant to the solution, please consider the creation of hashes out of scope.
Some users of M are using Moodle's built-in authentication. However, unless it is particularly relevant to the solution, please consider the migration of users out of scope.
I'd prefer O to manage users, if possible. M, by nature of being Moodle, will have to have its own records for the users, but I'd like it if they were similar to the records used by the external DB plugin: just saying that the user exists and can be found elsewhere.
Things I have tried, investigated, or considered:
Moodle's external database plugin. This is how it works at the moment. It sort of works, but requires multiple logins.
Automating the multiple logins. I've experimented with taking the posted credentials, making a HTTP request from the server to the sites' respective login forms when logging in, lifting the cookie out of the response, then sending that cookie back to the client. This also works, but it's clunky at best, and is reliant on the cookies not getting out of sync.
Using PHP's DOTNET library and doing...something. All of the documentation that I can find says that DOTNET does not work with anything other than .NET 2.0, 3.0 or 3.5. I'm using 4.5.2, so this seems like a no-go. I don't know what I'd do even if I could get it to work with more recent versions of .NET.
Somehow getting Moodle to accept the ASP.NET Identity cookie in place of its own. This seems like the most fruitful course, given that it is a single cookie to manage.
To wrap up: I'd like to make M and O share authentication. If they have a single login page, so much the better, but logging in to one should automatically log into the other; logout should also be shared. Is this possible, and does anyone know how I should go about it?
Maybe take a look at SAML.
I believe that .NET 4.5 supports SAML?
https://msdn.microsoft.com/en-us/library/ms733083%28v=vs.110%29.aspx
On the server, install simplesamlphp.
https://simplesamlphp.org/docs/stable/simplesamlphp-sp
It can be used both as a service provider and as an identity provider.
Then install this SAML plugin in Moodle :
https://moodle.org/plugins/auth_saml
Related
I couldn't find information on how other people solve this, so maybe you can help me out.
What I have
Multiple Services with REST APIs, that are secured using OpenID Connect. Connections between the Services work fine.
Now I have multiple developers, who sometimes need to write and execute local scripts (Python, R, Bash etc.) for quick analysis and testing.
What I want
I want to enable the developers to use the services as easy as possible, but still respecting security concerns.
What I tried
I defined the script itself as a client. Therefore I created a public client in my OIDC product, which is called somewhat like 'developer-scripts'. Using a library which handles the oauth dance, I can then execute the script connecting as aforesaid client. First time, the browser pops up and requests the user to authenticate and therefore authorize the client to use the REST API on behalf of the user. After that, the tokens are cached and I can easily continue working on that script.
This simplified drawing tries to summarize, what I just described
That works perfectly fine and regarding security I'm glad that credentials are not saved on the local computers as it was before with e.g. Basic Authentication. Furthermore, I'm able to control the access to different services on a user level.
Other ideas, which didn't convince me:
every web service also has an public client which can then be used as a client by the scripts (so the scripts aren't defined as clients anymore)
token generation is done somewhere else and the developer just adds the generated access/refresh token to the script
My problem
What concerns me about my current solution is the definition of that client. In the described case it would be either a generic client used by all developers for all scripts, or a new client for every developer who want's to write a local script. The latter seems to be a lot of overhead, the former may be a security problem?
So finally I'm asking the question: Are there any known best practices for my described use case?
EDIT:
I found a small article by [Martin Fowler](https://martinfowler.com/articles/command-line-google.html), he is basically explaining, how he is receiving a token to use for a local script. But in his case, he's using it for one certain use case, and not as a general public client. So unfortunately it doesn't really contribute to my answer.
here is a old version:https://wiki.jasig.org/display/CAS/Using+CAS+without+the+Login+Screen
I need to do the same with that latest version of CAS i.e. 3.5 . Can anyone provide me the steps for the same
We are doing now basically what you're asking here in my company. We have a Sharepoint website that in background is using the RESTful services for doing the real login. I wrote some posts about them in my blog and recently we used it to get access from a iOS application which contains a link to a sample program.
Important!!! We have a modification in our CAS that offers the possibility to use it for more than one domain. So wherever you find a reference to something called "Domain" in my samples just remove it, as it will not work on standard CASes
Here is a nice solution to your problem.
Just enable restful access.
My team has a rather large web application that was built with the Zend Framework, which has become mission-critical to our organization in the past year. It was built as part of an existing ZF corporate web site that no longer meets our needs.
The ZF app has its own users table in a database. It also uses Zend_Acl, and some database tables, to control access to modules, and to individual records. The records largely pertain to people in the system.
Thanks to new business needs, we're now faced with building a new public web site in Joomla. So, we need: (1) to keep running the old system, in some capacity, and (2) a shiny new Joomla site, (3) integration between the two.
-We can't move custody of the users away from our legacy system, because the people those users represent are elemental to the legacy system's purpose.
-We need the usernames and passwords to be the same, and work the same (we have a 60 day reset policy, our usernames aren't fixed values / are a bit convoluted)
-I looked at Zend_Ldap hoping I could expose our users to Joomla that way, but it seems to be just an LDAP client, and I'm not sure implementing an Ldap server in Zend that uses our existing tables is a good use of time. An extension that replaces Joomla's authentication would probably be wiser.
-Can our ACL control Joomla or should we have two ACLs exist in parallel.
-Do we write SOAP services in the Zend app to expose the data to the extension, or do we just give database credentials to the Joomla extensions directly.
A pretty broad question, I know, but I am only looking for broad answers: how would you tackle this?
Thanks!
The first step sounds like integrating the Auth system across Joomla! and your ZF app from there you can direct link to the ZF App's pages for logged in users. I would recommend the use of JFusion to integrate the Joomla! authorisation process and match the ACL groups across the two systems. You will have to write your own plugin for JFusion but that will be very simple compared to porting your entire app to a Joomla! extension. JFusion's GitHub repo is here.
Given the data provided you will need to run the ZF App as the master for authentication and sync user data to Joomla! via your custom plugin.
Once you have your plugin doing the authentication you can use JFusion's direct link mode to link to the ZF App as user that login to Joomla! will be automatically logged into the ZF app (and vice versa).
Hi I am using CAS for SSO. But problem is that i want reset password,register new user on CAS login screen.Does CAS provide these services or i have to implement?
Or Any other SSO solution exist which fulfill my requirement.
CAS is just a SSO frontend to your existing identity management solution (database, LDAP etc). It does not include any identity management features itself (create user account, reset password etc). I have recently been using the Cloudseal platform which is a full identity management solution and so far I am pretty impressed. I believe Atlassians Crowd also includes this although I have not used it. There are probably other products out there as well.
Both of these are commercial products although they are both free for the first 50 users. Crowd is a traditional standalone platform which you download, install and configure but Cloudseal is a hosted service so there is no installation and less config.
You can certainly modify the spring weblog and login page to allow for the functionality that of course you'd have to implement. You should also ask the question on #cas-user mailing list to see if a similar need in the community has been implemented by other users which you may be able to take advantage of. I remember only recently someone raised the same question to the list and there was a bit of interest in getting this feature developed and integrated. You may want to revisit the topic on the mailing list.
Hope this helps.
I want to keep things as simple as possible and I don't want a complicated security mechanism. Basically I need for a user an ID and an e-mail address and I really don't want to bother about other things. Also, I was a minimum overhead in terms of security (if there is anoter provider who can do it for me, that's even better).
What is the simplest way to do this? I was thinking about incorporating LiveID or OpenID by I don't know what are the advantages/disadvantages.
I am working with the Azure SDK.
If you use the Windows Azure Access Control Service, you can basically outsource all identity management. Take a look at the Windows Azure Platform Training Kit - there's a lab called "Introduction to the AppFabric Access Control Service 2.0" that will get you up and running quickly. Currently, you can choose any combination of the following identity providers:
WS-Federation
Facebook
Windows Live ID
Google
Yahoo!
"Simple" for whom?
The simplest strategy for you would probably be to use ASP.NET's standard SQL-based authentication provider. You just run a script against your database to set up all the tables, and then you use ASP.NET's built-in utility methods to authenticate. Give your user-specific tables a foreign key reference to that user's ID, and you're good to go. We've done this, and never had any trouble with it. It's a tried and well-used system, so you know you won't be introducing any security invulnerabilities by hacking your own solution together. (see SqlMembershipProvider vs a custom solutions)
If you want something simple for the user, then an OpenId solution would be my pick. Set up something like StackOverflow has, where you can let users choose an account from a number of trusted providers to allow them to log in. From the user's perspective, it's really nice not to have to remember one more username and password for one more site.