How to retrieve SP required attributes at the IDP before authentication

[Dierick Bart]

Hey everyone, 

At the moment I'm working on a project in Shibboleth to create a new strong authentication and autorisation mechanism. At the moment the improved authentication phase is completed. But for the next step I'm a bit in trouble. 

In my implementation, the required attributes (for the SP) already have to be know before starting the authentication (so my loginhandler is loaded and then I need to know and retrieve the SP required attributes) before completing the authentication. 

After a lot of research I realised that it must be possible to provide the required attributes at the authentication request. I found inspiration at 

https://spaces.internet2.edu/display/InCCollaborate/SP+Attribute+Requirements

They suggest that the required attributes can be setted in the metadata OR in the authentication request. 

I was already able to put these attributes in the the metadata. But isn't it better to get these attributes in the authentication request? And by value instead of by reference? 

I don't find any information on how to force the Shibboleth SP to provide the required attributes in the saml2 authentication request. 

So my questions are: 

1) Is it possible to provide the required SP attributes before the authentication? 
2) What is the best (if I need the attributes in my loginhandler)? Get them out of the metadata of the SP or in the authentication request by value or reference? 
3) Is it than possible to use these attribute (information) in my loginhandler? 

Greetings 

[Paul Hethmon]

If you wanting Shibboleth IdP to resolve and populate attributes prior to authentication, then no, it is not designed to support that. It's not clear to me if you are wanting the list of requested attributes for a particular SP or a list of the attribute values for an SP for a particular user. You would have access to the list of requested attributes as stored in the metadata file for the SP inside of your login handler.

If you are more talking about the attribute values, then the only way to do that would be to resolve them your self during authentication. I do this myself as my authentication process returns information about the user. I then put that information in the session where my custom attribute resolver gets them when Shib runs the attribute code.

Does that help?

Paul

[Cantor, Scott]

On 3/21/12 11:47 AM, "Dierick Bart" <bart.d...@hotmail.com> wrote:
>After
>a lot of research I realised that it must be possible to provide the
>required
>attributes at the authentication request.

If you define an extension and convince everybody to support it.
Otherwise, no.

>They
>suggest that the required attributes can be setted in the metadata OR in
>the
>authentication request.

They are wrong, there is no extension in SAML that permits the latter.

>I was already able to put these attributes in the the metadata. But isn't
>it
>better to get these attributes in the authentication request? And by
>value
>instead of by reference?

Not particularly, unless you think the request would be constantly
changing based on factors that an SP would know about.

-- Scott

--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net

[Dierick Bart]

No; in my loginhandler I just need to know wich attributes the Service Provider needs. What I'm going to do is:

 

1) the Service Provider forwards to the IDP

2) the IDP chooses my loginhandler

3) my loginhandler creates and shows a servlet. That servlet ask for authentication AND it shows which attributes the Service Provider needs

4) the user authenticates AND provide the attributes

5) the authentication is completed, the attributes are PUSHED to the Service Provider.

 

 

So the loginhandler needs the info about the required attributes so that the user can provide these attributes.

 

So you suggest and says that this (is only) possible with the metadata?

 

Greetings

[David Chadwick]

Hi Bart

you have now (re)uncovered the same problem that I notified to Scott
several years ago i.e. the ability for an SP to dynamically request a
set of attributes from an IDP. We did produce a draft SAML extension for
this, but Scott said there was no interest in standardising this in the
OASIS group at the time.

We have implemented various different ways of solving the problem, one
of which uses metadata (but this is not properly supported in all
implementations).

Our latest attempt was presented at the fall Internet 2 workshop here,
http://events.internet2.edu/2011/fall-mm/agenda.cfm?go=session&id=10001962&event=1148
This generally does not require any changes to the SAML protocol, since
it only uses the SAML Attribute Request message, which allows different
attributes to be dynamically requested.

If the time is now ripe to try again, then we can let you have a copy of
our proposed changes to SAML

regards

David

--

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Ch...@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

[Cantor, Scott]

On 3/21/12 2:20 PM, "David Chadwick" <d.w.ch...@kent.ac.uk> wrote:

>Hi Bart
>
>you have now (re)uncovered the same problem that I notified to Scott
>several years ago i.e. the ability for an SP to dynamically request a
>set of attributes from an IDP. We did produce a draft SAML extension for
>this, but Scott said there was no interest in standardising this in the
>OASIS group at the time.

No. What I said was, I had no interest (and I still don't). I'm not going
to edit, shepherd, and then implement something I don't think solves a
compelling problem lots of people are asking me to solve. That doesn't
stop anybody else from doing any OASIS work they like, or ignoring OASIS
and just writing it.

[David Chadwick]

Scott

this is rather disingenuous of you, given that you were not an author of
the draft document, and were not proposed to be. Coupled with the fact
that prior to the draft that George Inman and myself wrote, an earlier
one addressing the same topic and written by Sampo Kellomaki, was also
turned down by the SAML group for standardisation, shows that there was
some significant opposition to it.

So, whilst the ability to dynamically request attributes from an IDP
along with the authentication request, has been an item of interest to
several different researchers over the years, it has not been something
that the OASIS group has wanted to support (to date). It is possible to
dynamically request attributes using the Attribute Query after an Authn
Query, but this requires two round trips. What we proposed was an
enhanced Authn Request that allows it to be done in a single round trip.

Given the fact that you are not being asked to edit or shepherd the
document, and the draft already exists, if it was re-submitted to the
OASIS group, do you think there would still be strong opposition to it
being standardised?

regards

David

--

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Ch...@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

[Cantor, Scott]

On 3/21/12 3:22 PM, "David Chadwick" <d.w.ch...@kent.ac.uk> wrote:
>
>this is rather disingenuous of you, given that you were not an author of
>the draft document, and were not proposed to be.

Now you're being disingenuous, because if that were true, you would not
have needed my input or agreement at all.

> Coupled with the fact
>that prior to the draft that George Inman and myself wrote, an earlier
>one addressing the same topic and written by Sampo Kellomaki, was also
>turned down by the SAML group for standardisation, shows that there was
>some significant opposition to it.

That is not true. Sampo submitted an unfinished proposal, and then was no
longer actively pursuing it in the TC. His reasons are his own. Sorry, but
that is not "turned down" nor was there ever "opposition". In fact, my
recollection was that I noted the fact that multiple people had proposed
the idea and that they ought to talk about it so that a single proposal
would be worked on.

The SSTC has worked on a number of documents that I had no interest in, or
even disagreed with in some cases. As long as the documents were properly
written, correctly specified, and not a complete disaster, I have never
opposed them in any way. In fact, I've done more than my share of
commenting and correcting on such documents.

>So, whilst the ability to dynamically request attributes from an IDP
>along with the authentication request, has been an item of interest to
>several different researchers over the years, it has not been something
>that the OASIS group has wanted to support (to date).

That simply isn't true.

>Given the fact that you are not being asked to edit or shepherd the
>document, and the draft already exists, if it was re-submitted to the
>OASIS group, do you think there would still be strong opposition to it
>being standardised?

There never was any opposition at all, whatever you seem to think. But if
the submission is a mess with invalid XML, misuse of the schema, or other
deficiencies, or isn't in the right format, then no, it's not going to
just magically be accepted. Somebody has to do the work. In the TC. You
can't even submit anything if you're not part of the TC.

[David Chadwick]

I am a member of the TC, so I will submit the draft and see what
reception it gets.

regards

David

--

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Ch...@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

[Chad La Joie]

That is defined by the SAML metadata specification which you can get
from the OASIS website.

On 3/22/12 9:45 AM, Dierick Bart wrote:
> At the moment I don’t have the time to alter or implement the SAML
> messages and implementation of Shibboleth in order to support single
> round trip. I’ll have to use the metadata I’m afraid. If someone has
> some more documentation about this topic, I’d like to receive it.
>
> Thanks

[David Chadwick]

Note that some implementations (such as simpleSAMLPHP I believe) dont
support the metadata correctly, and will only ever pick up the first set
of attributes that are specified ie. they are incapable of supporting
multiple different sets

regards

David

On 22/03/2012 13:45, Dierick Bart wrote:
> At the moment I don’t have the time to alter or implement the SAML
> messages and implementation of Shibboleth in order to support single
> round trip. I’ll have to use the metadata I’m afraid. If someone has
> some more documentation about this topic, I’d like to receive it.
> Thanks
>
>
> --
> To unsubscribe from this list send an email to dev-uns...@shibboleth.net

--

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Ch...@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************