Task:Single sign-on/Status
This wiki page should give an update of the current status of the SSO implementation for the maemo.org components. The concept behind it and the reasons for the chosen implementation can be found here: Task:Single_sign-on
Contents |
[edit] SSO Status meeting 23-07
Wiki is fully integrated
- sign-in and sign-out
User information
- All editing interfaces should redirect to Midgard n.n.account
- Registration also happens there
- Niels has documented what data we need to manage
- Add to the n.n.accounts DM2 schema
- When user is edited in Midgard we should push the data to backend
- which will notify other services
- done as MidCOM watcher in the org.maemo.cas component
User information exchange
- Web services on top of Midgard MVC (midgard2)
- PULL interface that services can poll
- Changes since transaction ID XX
- PUSH interface for notifying services about changes
- webhooks http://blog.webhooks.org/about/
- Implementation
- Additional software (on the same server as CAS?)
- midgard2
- mysql (for userdata storage)
- Midgard MVC component for providing the web services
- JSON as transfer medium
- SSL client cert authentication between services and the Midgard2 instance
- CAS talks directly to MySQL
- CAS needs just username and password in some table (encryption?)
- The protocol specification needed ASAP (Alexey)
- Look up similar implementations in other web services
- Additional software (on the same server as CAS?)
[edit] Discuss it!
If you have suggestions, ideas, comments or questions feel free to join #maemo-meeting, 27.05. 12:00 UTC
[edit] In short - the main results of the meeting
Besides a general status update, here in a few words the main results of the meeting:
[edit] User management
- Centralised in one component
- Implemented on top of Midgard
- Infrastructure and UI already there
- Only modifications instead of rebuild from scratch
- Stored in a LDAP directory
- Applications...
- ...request the data from the user management system
- ...still have there own, local database
- ...offer endpoint, which can be pinged by the user management system to inform, that user data has been changed
[edit] Data merging
- First proposal 2-way merge, but problem with talk, as mostly different from the rest
- Better (or additionally): First login into new system request user to specify user names and passwords of all components and merge them under the new account
[edit] Keep informed
Here, in the monthly sprints and on my blog you can get always the newest information on the topic. In a couple of weeks we will meet again to discuss the status. I hope there will be a lively discussion in the meanwhile to get new ideas, comments and suggestions.
[edit] Test environment setup
Here you find the current status of the test environment. It is not meant for testing, but it should inform about the status right now.
Authentication Server
- Instance of CAS running on the test server
- Apache Tomcat used as servlet container
- Secure connection
- self signed certificate used for testing purposes
- LDAP directory used for user authentication (running on virtual machine)
Mediawiki
- Instance of mediawiki running on the test server
- Apache web server used to host the wiki
- CAS authentication integrated
- User can log in and logout using CAS
- Single sign-out now working
GForge
- Instance hosted by apache web server running in test environment
- Integration ongoing
User Management System
- Abstracted of the others components
- Should contain all the user related data
- Applications could request data from it
- Right now just a UI as a user registry
[edit] Issues
- ISSUE: LDAP/registry not over secure connection
[edit] Next steps
- Full integration of GForge
- Concept user data management -> apart from CAS
- Merging of different userdatabases (bugzilla, talk, midgard)
- Midgard integration
- Getting Wiki, Midgard, GForge in a shape for public testing
[edit] Future Plans
- integration of bugzilla, talk
[edit] Open Questions
- How should the application get the data from the user management system
- First possibility:
- Just UI to register user and update data
- Other components get data by LDAP-access
- Second idea:
- Web UI for user
- REST API for applications
- First possibility:
- This page was last modified on 11 May 2010, at 08:38.
- This page has been accessed 8,142 times.