Separating UniAuth Core into separate repo

[askvortsov1]

This looks like an awesome, stable project! One issue though is that it's shipped as a monolithic system, which means that the idp core can't be used in other, non uniAuth based projects. I propose separating out core functionality into a second repo, and keeping this as a starting template/starting project example. @peppelinux what are your thoughts on this?

[peppelinux]

I completely agree. I'll put uniAuth app in a separate repo. Would we think about merging in It some idp/* preprocessors and things?

[peppelinux]

Mind also unical_accounts model, it's coupled with some attr processors

[askvortsov1]

I completely agree. I'll put uniAuth app in a separate repo. Would we think about merging in It some idp/* preprocessors and things?

Not 100% familiar with the codebase here, is this mainly the LDAP support? If this can be integrated into uniAuth Core that's definitely something that would be great to have, although I haven't worked with LDAP so I'm not sure how difficult it would be to integrate

[askvortsov1]

Mind also unical_accounts model, it's coupled with some attr processors

I'm not sure about forcing a user model onto potential users. I know that at least personally, my use case requires a custom user model, and I suspect that this is a common requirement. Are there any options to keep functionalities without requiring use of the user model?

[askvortsov1]

I completely agree. I'll put uniAuth app in a separate repo. Would we think about merging in It some idp/* preprocessors and things?

let me know when you set this up so that I can help and start making PRs!

[askvortsov1]

A few questions from a cursory look at the codebase (looks awesome btw!!):

1. Maybe we can consider allowing use of an external login form if user agreement isn't being used on a particular request?
2. Does the system use the metadata url attribute of the ServiceProvider model, or various attributes of the MetadataStore model? Also, would it make sense to have some form of foreignkey relationship from ServiceProvider to MetadataStore, and manage MetadataStore through an inline to simplify the admin interface a little? Still looking through the codebase and figuring out how you got this all working, so I might be completely uninformed about this

[peppelinux]

Ok @askvortsov1 I think that uniAuth can work without any custom user model and the actual monolitic project could be usefull to understand how to customize attr processors and things following the idp/ example.

Regarding LDAP, idp/ is an example that deal with it in two different way. Regarding your questions:

Maybe we can consider allowing use of an external login form if user agreement isn't being used on a particular request?

Are you talking about a asaml authn request as that "particular request"? Yes, I think that this could be done easily with a template inheritation. uniAuth.views.Login is a inheritation of Django LoginView, it works on a specified url path. Is this the correct answer or I dind't understand your question?

Does the system use the metadata url attribute of the ServiceProvider model, or various attributes of the MetadataStore model?

It works with the pysaml2 MetadataStore. I use uniAuth with many Metadatastore, also centralized MDQ services. We can put them in the settings file or, better, through the model admin. This latter doesn't require any restart of django (enjoy).

Also, would it make sense to have some form of foreignkey relationship from ServiceProvider to MetadataStore, and manage MetadataStore through an inline to simplify the admin interface a little?

This is not required in a SAML2 federation, eduGain or inCommon federation have thousands of SP, we could not think to define them each one. Thee common approach is to federate automatically new SP accordly by their presence in the idp metadata store. This can be disabled through a global settings option if needed, see doc for better acknowledgements.

I'll put uniAuth in a separate app, I'll just ask you to decouple uniAuth project test/* to uniauth app. See also test/05 to understand how to play with an LDAP server easily.

If you need a fully compliant LDAP server for research and scholarship context please consider this: https://github.com/peppelinux/ansible-slapd-eduperson2016 and https://github.com/UniversitaDellaCalabria/django-ldap-academia-ou-manager

[peppelinux]

The only thing that should be refactored is this:

https://github.com/UniversitaDellaCalabria/uniAuth/blob/782f2f6e7653aa605be35483db82134e3c3a7524/uniauth/views.py#L422

I think to let the users choose a persistent storage for subjects ids, something like

if getattr(settings, 'SAML_PERSISTENT_ID_MODEL', None):
    ...

another in attr processor, regarding persistent subject id too: https://github.com/UniversitaDellaCalabria/uniAuth/blob/master/uniauth/processors.py#L63

[peppelinux]

@askvortsov1 sorry for the late, are you still interested to get in?

[peppelinux]

@askvortsov1 done here but still WiP.

Todo:

• setup.py and a general refactor of unit tests
• pypi package :)
• a general revision of the documentation

here: https://github.com/UniversitaDellaCalabria/uniAuth/commit/7350cfaaf23b5a65cdda9ab9d1edac2447babcf1

[peppelinux]

@askvortsov1 https://github.com/UniversitaDellaCalabria/uniAuth/releases/tag/2.0.0

stable release went in production, migrating a Shibboleth IdP 3.4.6 to uniAuth. A Success story :)