Skip to content
This repository has been archived by the owner. It is now read-only.

[dev.icinga.com #333] Finish user authentification concept #47

Closed
icinga-migration opened this issue Mar 12, 2010 · 9 comments
Closed

[dev.icinga.com #333] Finish user authentification concept #47

icinga-migration opened this issue Mar 12, 2010 · 9 comments
Labels
bug
Milestone

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Mar 12, 2010

This issue has been migrated from Redmine: https://dev.icinga.com/issues/333

Created by mhein on 2010-03-12 10:34:50 +00:00

Assignee: (none)
Status: Resolved (closed on 2010-08-18 10:15:14 +00:00)
Target Version: 1.0.3
Last Update: 2010-09-01 10:31:30 +00:00 (in Redmine)


Missing features:

  • HTTP BasicAuth (LoginForm)
  • Import users from other sources (LDAP, ...)

Changesets

2010-08-18 09:20:13 +00:00 by mhein ee51d10

* HTTP basic auth III (fixes #333)
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jun 4, 2010

Updated by mhein on 2010-06-04 13:43:13 +00:00

  • Target Version set to 1.0.3
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jul 21, 2010

Updated by mhein on 2010-07-21 07:42:55 +00:00

  • Done % changed from 0 to 60
  • LDAP finished
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jul 21, 2010

Updated by elagon on 2010-07-21 08:29:11 +00:00

I think the best solution is to just support the authentication "relay" from the web server, in that case you will support any authentication supported by the web server itself

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jul 21, 2010

Updated by Anonymous on 2010-07-21 11:07:30 +00:00

Are you thinking about B?

A)
Set Apache to relay pure LDAP auth and based on a config file, help Icinga to give the proper permissions.

B)
Let Icinga do LDAP and see the rights of the user in the Directory, ie group memberships(permissions), but let Apache itself handle the authentication?

C)
Let Icinga do all the LDAP, login and permissions(based on groups?).

I think C) would be best, unless some Apache guru can provide assistance with B) for large scale environments (100+ users)

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jul 21, 2010

Updated by mhein on 2010-07-21 11:17:19 +00:00

C is already implemented. The other problem on apache only based auth is that you need already created users. Therefore we need providers to import userdata into the system, and others which authenticate. You can not create and keep a setup in sync with 200+ users.

The problem with httpbasic is the login mask and the initial cookie creation step (I do not want to authenticate on all pages). I think we need a new mask with a button (You are XXX, press to proceed).

I think the "only" thing is a provider which authenticated agains the REMOTE_USER field.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jul 21, 2010

Updated by Anonymous on 2010-07-21 11:26:42 +00:00

ah, didnt know it was already in ;-)

Is this scenario possible?:
Make groups in Web(frontend!), that is linked to one or more groups in a LDAP source? Instead of having to admin+sync the users to Icinga itself, auth against the remote system and see what memberships the user has on login. Give permissions/roles based on that.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jul 21, 2010

Updated by mhein on 2010-07-21 12:23:52 +00:00

TheFlyingCorpse wrote:

ah, didnt know it was already in ;-)

Yes ;-) I should update the issues .....

Is this scenario possible?:
Make groups in Web(frontend!), that is linked to one or more groups in a LDAP source? Instead of having to admin+sync the users to Icinga itself, auth against the remote system and see what memberships the user has on login. Give permissions/roles based on that.

Yes, it is. But only one group with on provider, but you can use the same provider type several times. Each of them has it's own query to determine which user occurs in the group. If this user is found, the provider imports them and assign them to the belonging icinga group.

Here is an example: https://dev.icinga.org/projects/icinga-web/wiki/Insider\_tips#Ldap-authentication

But you have to take the group_map attribute from the global scope into the provider scope.

LG Marius.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Aug 18, 2010

Updated by mhein on 2010-08-18 10:15:14 +00:00

  • Status changed from New to Resolved
  • Done % changed from 60 to 100

Applied in changeset commit:"ee51d1006505edbbf8af13cfc8ace7d5d9c7bfee".

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Sep 1, 2010

Updated by mhein on 2010-09-01 10:31:30 +00:00

The algo:

- 1.0 User tries to login
- 1.1 Yes user is in the system
- Loading the belonging provider
- Provider can update (auth\_update)
- Update user profile
- Provider is 'authoritative'
- Authenticate against
- Fail and auth\_resume
- Try other provider in the configured order
- Iterate to all the others and try only
authenticate
- Fail and not auth\_resume
- NO LOGIN
- Provider is not authoritative and auth\_resume
- Try other provider in the configured order
- Provider is not authoritative
- NO LOGIN
- 1.2 NO user is not available
- Iterate through all providers
- Yes user is available on the provider
- Yes provider can import (auth\_import)
- Import the user profile and goto 1.1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.