Hi Pietro,

@Matteo: Yes, that is me! 

As for advice, Pietro, it sounds like you are on the right track...

Basically, this type of solution has three parts:

1) A part which handles the protocol-specific stuff, SPNEGO, SAML, OAuth or 
whatever. Sounds like for you this is the http filter supplied by the SPNEGO 
library.
2) A part which links the information recovered from the protocol to the 
magnolia login and user database. --> this is normally in the form of a 
"LoginHandler" implementation
3) A part which handles the case that a request requires privileges that the 
current user doesn't have. --> this is normally in the form a "ClientCallback" 
implementation

It sounds to me like you have 2) covered, and there is currently some problem 
with 1) and 3). It sounds to me like your SpnegoHttpFilter is not only handling 
the SPNEGO authentication when present in the request, but also sending the 
"SPNEGO challenge" if the request is not authenticated.
This is the normal behavior used in most simple web applications, but probably 
not the behavior you want with magnolia. You would prefer something like: 
- a filter which handles the SPNEGO information if present in the request, and 
ignores (passes through) the request otherwise
- a LoginHandler which reads the information found by the SPNEGO filter, if 
present, and performs a login (sounds like you have this part working)
- a ClientCallback which triggers the SPNEGO challenge for certain requests (?)

So it looks like you will have to modify (or subclass and override) the filter 
a little bit to not send the challenge, and then implement a ClientCallback 
which sends the challenge instead.

Also, as a hint, you can configure any http filter right within magnolia in 
magnolia's filter chain (under config->/server/filters/... ). So you can 
configure your SpNegoFilter there and don't need to modify the web.xml.


As for your second problem, be sure to test with a normal user first, before 
you try with the public users. If the login is working for a user configured 
with role "superuser", and the apps are visible, then it is almost certainly a 
permissions problem on your public users. In theory there is no reason why 
public users can't use apps if you give them the right permissions.


Regards from Vienna,

Richard



> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:user-list-owner@magnolia-
> cms.com] Im Auftrag von Matteo Pelucco (via Magnolia Forums)
> Gesendet: Donnerstag, 03. April 2014 08:55
> An: Magnolia User List
> Betreff: [magnolia-user] Re: Magnolia and integrated Windows
> Authentication
> 
> That's Richard! :) Maybe he can give more advices on this topic..
> M.
> 
> --
> Context is everything: http://forum.magnolia-
> cms.com/forum/thread.html?threadId=d88afb83-74bb-4fe5-84f2-
> f4fdebf2f056
> 
> 
> ----------------------------------------------------------------
> For list details, see http://www.magnolia-cms.com/community/mailing-
> lists.html
> Alternatively, use our forums: http://forum.magnolia-cms.com/
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------



----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to