Better approach to do Authorization in shibboleth

[Eric Goodman]

I’ll add in my own attempt at explaining as well. You seem to be thinking that you have to do something much more complicated than what is actually necessary, so may be overlooking the specific advice because it seems “too easy”. In particular, there is no need for custom coding in the IdP to do any of the things you are asking about.

What you need to do is answer these questions:


1)      What data elements does the SP need from the IdP describing the logged in user?

a.       This tells you what attributes need to be defined (in attribute-resolver.xml)

b.      It also tells you what attributes need to be released to each SP (in attribute-filter.xml)

2)      What data source contains this attribute?

a.       This tells you what data connectors you need defined (again in attribute-resolver.xml). Usually the data connector will already exist, but if you need data from a second “server”, you may need to create an additional one.

That’s it on the IdP side. There’s literally nothing else to do. No custom programming, no additional SAMLRequests. None of the code you’ve posted is relevant to your question of “What should the IdP do?” because your question has been answered.

When you configure the above settings, the AuthnResponse you get from the IdP will have the user principle AND all necessary attributes in it.

As other people have pointed out, nothing the IdP is doing is directly authorization. The IdP is providing information used for authorization, but it doesn’t do any (and shouldn’t do any) actual authorization itself. The IdP releases the attributes to the SP, and then it is done. The SP is then responsible for receiving and validating these attributes and handing them off to the application. The application then uses the values of the attributes to determine what authorization the user should have. The only step where granular authorization is actually happening is within the application. The IdP and the SP are simply passing along attributes.

Because you’ve stated you’re writing your own SP, any questions about “how does the SP do this?” are beyond the scope of this list.

--- Eric


From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Surinaidu Majji
Sent: Tuesday, December 02, 2014 10:44 PM
To: Shib Users
Subject: Re: Better approach to do Authorization in shibboleth

Hello Paul,
I am really very happy that i am getting lot of information from the Shib Users like you, but i do not know why i am not able to get the exact information which i required. I think i got the replies for my query but i could able to understand properly.

Here my actual requirement is:
Now i am using shibboleth idp which we own(External Idp) to do authentication. Here i use 'ExternalAuthn' Login handler in handler.xml. Now the authentication is done by checking the credentials(from login.jsp) with our Server(database)

- The current requirement is like instead of using our Server to validate credentials(from login.jsp), i have to link this external idp to other Server (database).
That's why i wanted know about authorization for my application, but i could not able to achieve it.
Please consider my request, because i do not have any other source to get my requirement done, If require i will post my entire authentication procedural steps which i have right now in my existing application.

On Tue, Dec 2, 2014 at 7:33 PM, Paul Hethmon <paul.hethmon at clareitysecurity.com<mailto:paul.hethmon at clareitysecurity.com>> wrote:
On Dec 2, 2014, at 6:59 AM, Surinaidu Majji <pioneer.suri at gmail.com<mailto:pioneer.suri at gmail.com>> wrote:

Thank you for your reply, but you are saying attributes pulled from resolver:
Is that attribute-resolver.xml, configured for releasing attributes, in that case
i am releasing 'principal' which contains 'permissions' to SP. Is that right?


attribute-resolver.xml defines attributes and the sources to obtain those attributes. That includes the “principal” and anything else you might define.

attribute-filter.xml defines which SP’s get which attributes released to them.

None of that is “permissions” in the sense that to the IdP the attributes are opaque values sent to an SP. There is no inherent meaning of those attributes at the IdP level. At the SP level it has to define what those attributes mean.

Paul



——

Paul Hethmon
Chief Software Architect
paul.hethmon at clareitysecurity.com<mailto:paul.hethmon at clareitysecurity.com>



--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20141203/ef93816f/attachment-0001.html