Better approach to do Authorization in shibboleth
Surinaidu Majji
pioneer.suri at gmail.com
Thu Dec 4 06:35:54 EST 2014
Hello Eric, thank you for your effort putting to answer my question.
1) What data elements does the SP need from the IdP describing the
logged in user?
Ans: My answer is yes, I know what data i want to get at SP side, here i
want to get the permissions of the logged in user to decide for which
modules loggedin user has permissions.
- Right now, i am only getting the 'Principal' at SP side, which
contains information about the user(email, acctType) etc. As per my
understanding i am getting the principle because of below code:
step:1) after authenticating against database when request goes from
login.jsp:
===============================================
The request is going to IDP(AuthenticationEngine) along with the principal
request.setAttribute(globalStrings.getForceAuthn(), false);
Principal principal = new UsernamePrincipal(login.getAttributes());
Subject subj = new Subject();
subj.getPrincipals().add(principal);
request.setAttribute(LoginHandler.PRINCIPAL_KEY, principal);
request.setAttribute(LoginHandler.PRINCIPAL_NAME_KEY, personId);
request.setAttribute(LoginHandler.SUBJECT_KEY, subj);
request.setAttribute(globalStrings.getAuthnMethod(),
this.authenticationMethod);
AuthenticationEngine.returnToAuthenticationEngine(request, response);
step-2):
To release the attributes at SP side, i configured the attribute-resolver,
attribute-filter like below:
====================================================================
*attribute-resolver.xml:*
<resolver:AttributeDefinition id="principal" xsi:type="PrincipalName"
xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" />
<resolver:AttributeEncoder xsi:type="SAML2Base64"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="ORG_ATTRIBUTE_64" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="ORG_ATTRIBUTE" />
*attribute-filter.xml:*
<afp:AttributeFilterPolicy id="releaseBasicAttributesToAnyone">
<afp:PolicyRequirementRule xsi:type="basic:ANY"/>
<afp:AttributeRule attributeID="principal">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
Because of above two steps i am getting the principal at SP
side(SAMLResponse)
*Please correct me if i am wrong.*
if i am correct, Like this can we get the permissions of the user, Please
give me an example to get the permissions of the user at SP side in saml
response.
2) What data source contains this attribute?
- Here the only source is our database for every information, I can get the
info from database by sending request with proper url.
Please provide me some example with xml configuration, So that i can easily
handle my task.
Thank you.
On Thu, Dec 4, 2014 at 1:29 AM, Eric Goodman <Eric.Goodman at ucop.edu> wrote:
> 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> wrote:
>
> On Dec 2, 2014, at 6:59 AM, Surinaidu Majji <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
>
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20141204/3c4e556b/attachment-0001.html
More information about the users
mailing list